@nx/devkit - npm Package Compare versions

Comparing version 23.0.0-beta.17 to 23.0.0-beta.18

dist/src/migrations/update-23-0-0/update-deep-imports.md

+#### Update `@nx/devkit` deep imports
+
+`@nx/devkit` now ships a strict `exports` map, so deep imports like `@nx/devkit/src/utils/...` and `@nx/devkit/src/generators/...` are no longer reachable through Node module resolution.
+
+This migration scans every `.ts`, `.tsx`, `.cts`, and `.mts` file in your workspace and rewrites those deep imports to one of the supported entry points:
+
+- Symbols that are part of the stable `@nx/devkit` public API are routed to `@nx/devkit`.
+- Symbols that were previously only reachable through deep imports are routed to `@nx/devkit/internal`.
+
+After rewriting, the migration **collapses duplicate imports** so a file never ends up with two `import ... from '@nx/devkit'` (or `@nx/devkit/internal`) lines — including merging into any matching import you already had.
+
+#### Sample Code Changes
+
+##### Before
+
+```ts
+import { Tree } from '@nx/devkit';
+import { dasherize, names } from '@nx/devkit/src/utils/string-utils';
+import { addPlugin } from '@nx/devkit/src/utils/add-plugin';
+```
+
+##### After
+
+```ts
+import { Tree, names } from '@nx/devkit';
+import { dasherize, addPlugin } from '@nx/devkit/internal';
+```
+
+`names` was already in the public API, so it joins the existing `@nx/devkit` import. `dasherize` and `addPlugin` move to `@nx/devkit/internal`, and the two `/internal` imports are collapsed into one.
+
+#### Fallback for non-named imports
+
+For deep-import shapes that can't be split by symbol — default imports, namespace imports, side-effect imports, `require(...)` calls, dynamic `import(...)`, and `jest.mock(...)` / `vi.mock(...)`-style mock-helper calls — the migration rewrites the specifier to `@nx/devkit/internal` as a best guess, since most symbols that previously lived under `@nx/devkit/src/...` ended up there.
+
+```ts
+// Before
+const { dasherize } = require('@nx/devkit/src/utils/string-utils');
+
+// After
+const { dasherize } = require('@nx/devkit/internal');
+```
+
+If the symbol you're after is part of the stable public API instead, the rewritten import will fail to resolve against `@nx/devkit/internal` — switch it to `@nx/devkit` by hand. The migration also leaves `typeof import('@nx/devkit/src/...')` type queries and any deep-import strings inside template literals or comments untouched, so you'll need to update those by hand.

dist/src/migrations/update-23-0-0/update-deep-imports.js

@@ -63,2 +63,4 @@ "use strict";
     'dasherize',
+    'emitPluginWorkerLog',
+    'throwForUnsupportedVersion',
 ]);
@@ -65,0 +67,0 @@ // Methods on `jest` and `vi` that take a module specifier as their first

package.json

 {
   "name": "@nx/devkit",
-  "version": "23.0.0-beta.17",
+  "version": "23.0.0-beta.18",
   "private": false,
@@ -63,3 +63,3 @@ "type": "commonjs",
     "jest": "30.3.0",
-    "nx": "23.0.0-beta.17"
+    "nx": "23.0.0-beta.18"
   },
@@ -66,0 +66,0 @@ "peerDependencies": {

New alerts

Shell access

Supply chain risk

This module accesses the system shell. Accessing the system shell increases the risk of executing arbitrary code.

Found 1 instance in 1 package

Uses eval

Supply chain risk

Package uses dynamic code execution (e.g., eval()), which is a dangerous practice. This can prevent the code from running in certain environments and increases the risk that the code may contain exploits or malicious behavior.

Found 1 instance in 1 package

Debug access

Supply chain risk

Uses debug, reflection and dynamic code execution features.

Found 1 instance in 1 package

Dynamic require

Supply chain risk

Dynamic require can indicate the package is performing dangerous or unsafe dynamic code execution.

Found 1 instance in 1 package

Environment variable access

Supply chain risk

Package accesses environment variables, which may be a sign of credential stuffing or data theft.

Found 8 instances in 1 package

Filesystem access

Supply chain risk

Accesses the file system, and could potentially read sensitive data.

Found 1 instance in 1 package

Long strings

Supply chain risk

Contains long string literals, which may be a sign of obfuscated or packed code.

Found 1 instance in 1 package

URL strings

Supply chain risk

Package contains fragments of external URLs or IP addresses, which the package may be accessing at runtime.

Found 1 instance in 1 package

Fixed alerts

Shell access

Supply chain risk

This module accesses the system shell. Accessing the system shell increases the risk of executing arbitrary code.

Found 1 instance in 1 package

Uses eval

Supply chain risk

Package uses dynamic code execution (e.g., eval()), which is a dangerous practice. This can prevent the code from running in certain environments and increases the risk that the code may contain exploits or malicious behavior.

Found 1 instance in 1 package

Debug access

Supply chain risk

Uses debug, reflection and dynamic code execution features.

Found 1 instance in 1 package

Dynamic require

Supply chain risk

Dynamic require can indicate the package is performing dangerous or unsafe dynamic code execution.

Found 1 instance in 1 package

Environment variable access

Supply chain risk

Package accesses environment variables, which may be a sign of credential stuffing or data theft.

Found 8 instances in 1 package

Filesystem access

Supply chain risk

Accesses the file system, and could potentially read sensitive data.

Found 1 instance in 1 package

Long strings

Supply chain risk

Contains long string literals, which may be a sign of obfuscated or packed code.

Found 1 instance in 1 package

URL strings

Supply chain risk

Package contains fragments of external URLs or IP addresses, which the package may be accessing at runtime.

Found 1 instance in 1 package

Improved metrics

Total package byte prevSize

304031

0.78%

Number of package files

125

0.81%

Lines of code

6975

0.03%

No dependency changes