fix(dotnet)!: graduate @nx/dotnet — drop experimental banner and the /plugin export#35895
Merged
Conversation
- Remove the "currently experimental" aside from the .NET plugin introduction docs page - Remove the matching experimental note from the published @nx/dotnet npm README template The plugin is no longer experimental, so these notices no longer reflect its status.
✅ Deploy Preview for nx-dev ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
✅ Deploy Preview for nx-docs ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
Contributor
|
View your CI Pipeline Execution ↗ for commit 3d62e07
☁️ Nx Cloud last updated this comment at |
- Drop the `./plugin` subpath from the package exports map; the plugin is now registered solely via the bare `@nx/dotnet` specifier - Inline the plugin re-export into `index.ts`, convert the internal plugin module to named exports, and delete the redundant `src/plugin.ts` shim - Add a migration that rewrites `nx.json` plugin entries from `@nx/dotnet/plugin` to `@nx/dotnet` Exposing both `@nx/dotnet` and `@nx/dotnet/plugin` was redundant and confusing since they resolved to the same plugin implementation.
FrozenPandaz
approved these changes
Jun 5, 2026
AgentEnder
changed the title
Co-authored-by: Jason Jean <jasonjean1993@gmail.com>
Loop over the `nx.json` plugins array and rewrite `@nx/dotnet/plugin` entries by index (string entries) or by mutating the object's `plugin` property, instead of rebuilding the array. This preserves each plugin's position, since plugin order is significant for target inference.
vrxj81
pushed a commit
to vrxj81/nx
that referenced
this pull request
Jun 7, 2026
…/plugin export (nrwl#35895) ## Current Behavior <!-- This is the behavior we have today --> - The `@nx/dotnet` plugin is labeled **experimental** in two user-facing places: the docs site introduction page (a `caution` aside) and the published npm README (generated from `readme-template.md`). - The package exposes the plugin via **two** specifiers: the bare `@nx/dotnet` and the `@nx/dotnet/plugin` subpath. Both resolve to the same plugin implementation, which is redundant and confusing. ## Expected Behavior <!-- This is the behavior we should expect with the changes in this PR --> - The experimental banner/warning is removed from both the docs page and the npm README. (Factual asides — .NET SDK compatibility, minimum Nx version — are kept.) - The `@nx/dotnet/plugin` subpath export is removed. The plugin is registered solely via the bare `@nx/dotnet` specifier (already what `nx add @nx/dotnet` / the init generator writes). - A migration rewrites any existing `nx.json` plugin entries from `@nx/dotnet/plugin` to `@nx/dotnet`, handling both the string and object (`{ plugin, options }`) registration forms and de-duplicating if both paths are present. ### Implementation notes - Removed the `./plugin` entry from the package `exports` map. - Inlined the plugin re-export into `src/index.ts`, converted the internal plugin module to named exports, and deleted the now-redundant `src/plugin.ts` shim. The bare `@nx/dotnet` public surface is unchanged. - Added the `update-23-0-0-migrate-dotnet-plugin-path` migration with unit tests (6 cases, all passing). **BREAKING CHANGE:** the `@nx/dotnet/plugin` entry point has been removed; use `@nx/dotnet`. The included migration updates `nx.json` automatically. ## Related Issue(s) <!-- Please link the issue being fixed so it gets closed when this is merged. --> N/A --------- Co-authored-by: Jason Jean <jasonjean1993@gmail.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Current Behavior
@nx/dotnetplugin is labeled experimental in two user-facing places: the docs site introduction page (acautionaside) and the published npm README (generated fromreadme-template.md).@nx/dotnetand the@nx/dotnet/pluginsubpath. Both resolve to the same plugin implementation, which is redundant and confusing.Expected Behavior
@nx/dotnet/pluginsubpath export is removed. The plugin is registered solely via the bare@nx/dotnetspecifier (already whatnx add @nx/dotnet/ the init generator writes).nx.jsonplugin entries from@nx/dotnet/pluginto@nx/dotnet, handling both the string and object ({ plugin, options }) registration forms and de-duplicating if both paths are present.Implementation notes
./pluginentry from the packageexportsmap.src/index.ts, converted the internal plugin module to named exports, and deleted the now-redundantsrc/plugin.tsshim. The bare@nx/dotnetpublic surface is unchanged.update-23-0-0-migrate-dotnet-plugin-pathmigration with unit tests (6 cases, all passing).BREAKING CHANGE: the
@nx/dotnet/pluginentry point has been removed; use@nx/dotnet. The included migration updatesnx.jsonautomatically.Related Issue(s)
N/A