This page documents the 0.4 release candidates of @nexusdi/core. The newest on npm is 0.4.0-rc.1. The documentation for 0.3.2, the current release, is at nexus.js.org. Try the release candidate.

Trying the 0.4 Release Candidate

NexusDI 0.4 introduces major changes to the container’s architecture, moving toward static graph validation. To ensure stability, the 0.4 release is published as a series of Release Candidates (RCs) before the final 0.4.0 version is released.

What is a Release Candidate?

A Release Candidate is a version that is functionally complete but is being tested for final bugs. RCs are published under the npm next dist-tag. RCs are versioned 0.4.0-rc.0, 0.4.0-rc.1 and onward.

For @nexusdi/core, latest remains on the stable 0.3.x line until 0.4.0 final, and next points to the most recent RC. A package that has never had a stable release, such as @nexusdi/testing, has latest on the newest RC as well. We encourage users to try the RC and report any issues to ensure the final release is as stable as possible.

An RC may break the previous RC, and the release notes of each RC list every breaking change. For the move from 0.3, read Upgrading to 0.4.

Installation

All @nexusdi/* packages share the same version. Each package names the exact version of @nexusdi/core it needs as a peer dependency. To try the RC, install the core and any necessary plugins using the next tag:

npm install @nexusdi/core@next
npm install -D @nexusdi/testing@next @nexusdi/devtools@next

A package installed without @next next to @nexusdi/core@next can resolve to a different version, and npm then reports the peer dependency mismatch.

Try it: Run the commands in the project Getting Started sets up, then run the first ship from that page.

Verifying Your Version

You can check which version of NexusDI you have installed using npm ls:

npm ls @nexusdi/core
npm view @nexusdi/core dist-tags

If you see a version like 0.4.0-rc.X, you are running the release candidate. npm view @nexusdi/core dist-tags shows what each dist-tag points at. It prints latest and next, and next names the newest RC.

These pages are built from the 0.4 release branch, which can be ahead of the newest RC on npm. The notice at the top of each page names the version the page documents. When the notice names a version newer than the one npm ls prints, the page can describe a change that the next RC publishes.

Reporting Problems

If you encounter a bug or a regression in the RC, report it via the RC feedback form . Post questions and general feedback in the “0.4 RC feedback” discussion under GitHub Discussions .

To help the maintainers fix the issue, include:

1. The output of npm ls @nexusdi/core and node --version.
2. The full error message, including the error code (e.g., [NEXUS_MISSING_PROVIDER]).
3. A minimal reproduction program that triggers the failure.
4. What you expected the program to do.

The region below is a starting point for the program. It builds one module with the mistake, catches the error, and prints the code and every inner message. Replace the declarations with the smallest part of your app that fails.

import { Nexus, Token, defineModule, isNexusError } from '@nexusdi/core';
import { provide } from '@nexusdi/core';
 
// Replace these declarations with the smallest part of your app that fails.
interface INavCharts {
  plot(to: string): string;
}
interface IShipComputer {
  course(to: string): string;
}
const NAV_CHARTS = new Token<INavCharts>('NavCharts');
const COMPUTER = new Token<IShipComputer>('ShipComputer');
 
class QuantumComputer implements IShipComputer {
  static deps = [NAV_CHARTS] as const;
  constructor(private readonly charts: INavCharts) {}
  course(to: string) {
    return this.charts.plot(to);
  }
}
 
const Engineering = defineModule({
  name: 'Engineering',
  providers: [provide(COMPUTER, { useClass: QuantumComputer })],
});
 
const error = await Nexus.create(Engineering).catch(
  (caught: unknown) => caught,
);
const code = isNexusError(error) ? error.code : null; // -> 'NEXUS_BLUEPRINT_INVALID'
console.log(code);
const inner = isNexusError(error, 'NEXUS_BLUEPRINT_INVALID')
  ? error.errors
  : [];
const messages = inner.map((each) => each.message); // -> ['[NEXUS_MISSING_PROVIDER] token=NavCharts requester=ShipComputer module=Engineering. https://nexus.js.org/errors/NEXUS_MISSING_PROVIDER']
console.log(messages);

Try it:

1. Save the region as repro.ts and run npx tsx repro.ts. The first line is NEXUS_BLUEPRINT_INVALID, and the second is one inner message, NEXUS_MISSING_PROVIDER, with the link to the page for that code. npx tsc --noEmit reports no diagnostic, because the mistake is a missing provider that only the container sees.

2. Add this class above Engineering, and add provide(NAV_CHARTS, { useClass: StarCharts }) to providers:

   Not run

   class StarCharts implements INavCharts {
     plot(to: string) {
       return `course set for ${to}`;
     }
   }

   Run again. The module builds, so the program prints null and [], and there is nothing to report.

3. Delete the provide(NAV_CHARTS, ...) line again and run once more. The two lines from step 1 print again.

The maintainers label critical bugs as rc-blocker. A bug with this label must be fixed before 0.4.0 final is released.

When 0.4.0 Final Is Released

The maintainers release 0.4.0 final once all three conditions hold:

1. Four weeks have passed since the last RC with a breaking change.
2. No issue labelled rc-blocker is open.
3. The nexusdi upgrade command, planned for @nexusdi/cli in a later release candidate, converts our 0.3 test codebases with no hand edits, and each converted codebase type-checks and passes its tests. The test codebases are every code example from the 0.3 docs and the 0.3.x examples, and a multi-package 0.3 app set up with npm workspaces, pnpm, Nx and Turborepo.