Improvements#480
Conversation
- Updated `@nx/*` packages and `nx` to `23.0.1` in `package.json`. - Synchronized dependency changes in `yarn.lock`. BREAKING CHANGE: Updated to Nx v23
… implementation - Adjusted `webpackExecutor` import path to reflect latest structure in `@nx/webpack`. - Replaced redundant `ExecutorContext` import with existing `@nx/devkit` re-export.
📝 WalkthroughWalkthroughWorkspace ignore rules and Nx analytics settings were updated, root and package manifests moved to Nx 23-compatible versions, and selected GCP Functions, Translations, Vercel, and shadcn-ui code paths were adjusted to newer Nx import and type forms. ChangesNx 23 upgrade
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes Possibly related PRs
Poem
🚥 Pre-merge checks | ✅ 3 | ❌ 2❌ Failed checks (1 warning, 1 inconclusive)
✅ Passed checks (3 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Warning There were issues while running some tools. Please review the errors and either fix the tool's configuration or disable the tool if it's a critical failure. 🔧 ESLint
ESLint install failed. For unrecoverable errors, disable the tool in CodeRabbit configuration. Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
- Updated all `@nx/devkit` peer dependency references from v22.0.0 to v23.0.0 across `yarn.lock`.
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🧹 Nitpick comments (2)
packages/translations/src/plugins/plugin.ts (1)
22-37: 🎯 Functional Correctness | 🔵 Trivial | ⚡ Quick winPreserve the plugin option type on
CreateNodesand handle undefined options.
CreateNodesis generic; omitting the type parameter defaults the options tounknown. The Nx 23CreateNodesFunctionreceivesoptions: T | undefined. The inner callbackcreateTargetsandnormalizeOptionsmust explicitly acceptundefinedto match the runtime behavior where options might not be provided.♻️ Proposed typing fix
-export const createNodes: CreateNodes = [ +export const createNodes: CreateNodes<TranslationPluginOptions> = [ '**/.translationsrc.json', async ( configFiles, - options: TranslationPluginOptions, + options, // Inherits T | undefined from CreateNodesFunction context ): Promise<CreateNodesResultArray> => { return createNodesFromFiles(createTargets, configFiles, options, context) } ] function createTargets( projectConfigurationFile: string, - options: TranslationPluginOptions, + options: TranslationPluginOptions | undefined, // Must handle undefined context: CreateNodesContext ): CreateNodesResult { // ... } - function normalizeOptions(options: TranslationPluginOptions) { + function normalizeOptions(options: TranslationPluginOptions | undefined) { // ... }🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@packages/translations/src/plugins/plugin.ts` around lines 22 - 37, The createNodes callback is losing its plugin option type because CreateNodes is used without the generic, and the options parameter is not aligned with Nx 23’s undefined-at-runtime behavior. Update createNodes in plugin.ts to preserve TranslationPluginOptions in the CreateNodes type, and make both the inner callback and createTargets/normalizeOptions explicitly accept TranslationPluginOptions | undefined so they match CreateNodesFunction and handle missing options safely.packages/shadcn-ui/src/generators/init/init.impl.ts (1)
12-12: 📐 Maintainability & Code Quality | 🔵 TrivialEncapsulate the
@nx/devkit/internalimport.Verification confirms that
determineProjectNameAndRootOptionsis not exposed from the public@nx/devkitentrypoint in Nx 23.x; the/internalpath is the only valid resolution given strict exports maps. However, since this entrypoint is explicitly a non-public escape hatch subject to instability, isolate the dependency to prevent scattered churn. Create a local re-export (e.g.,init/internal-utils.ts) that wraps this import, ensuring future Nx upgrades only touch this single adapter.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@packages/shadcn-ui/src/generators/init/init.impl.ts` at line 12, Encapsulate the non-public `@nx/devkit/internal` dependency used by determineProjectNameAndRootOptions so it is not imported directly from init.impl.ts. Add a local adapter module such as init/internal-utils.ts that re-exports this helper, then update init.impl.ts to import from that adapter instead; this keeps the internal Nx dependency isolated in one place for future upgrades.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@package.json`:
- Around line 53-55: The Jest dependencies are out of sync, with jest pinned to
an older version than jest-environment-jsdom and jest-util, so update the jest
package in package.json to match the same 30.4.1 version used by the other Jest
ecosystem packages; keep the versions aligned across the Jest entries to avoid
internal API mismatches.
In `@packages/gcp-functions/src/executors/build/build.impl.ts`:
- Around line 1-2: The build executor currently imports webpackExecutor from an
internal `@nx/webpack` dist path, which will break under Nx 23’s exports
restrictions. Update the build.impl.ts executor to use the public
`@nx/webpack`:webpack target through runExecutor from `@nx/devkit` instead of
calling the internal implementation directly, and adjust any
WebpackExecutorEvent/type usage to rely on public types or inferred executor
output so the `@nx-extend/gcp-functions`:build executor remains compatible.
---
Nitpick comments:
In `@packages/shadcn-ui/src/generators/init/init.impl.ts`:
- Line 12: Encapsulate the non-public `@nx/devkit/internal` dependency used by
determineProjectNameAndRootOptions so it is not imported directly from
init.impl.ts. Add a local adapter module such as init/internal-utils.ts that
re-exports this helper, then update init.impl.ts to import from that adapter
instead; this keeps the internal Nx dependency isolated in one place for future
upgrades.
In `@packages/translations/src/plugins/plugin.ts`:
- Around line 22-37: The createNodes callback is losing its plugin option type
because CreateNodes is used without the generic, and the options parameter is
not aligned with Nx 23’s undefined-at-runtime behavior. Update createNodes in
plugin.ts to preserve TranslationPluginOptions in the CreateNodes type, and make
both the inner callback and createTargets/normalizeOptions explicitly accept
TranslationPluginOptions | undefined so they match CreateNodesFunction and
handle missing options safely.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 12f01c5c-a978-4bf7-a8ce-0d9ede33d8c9
⛔ Files ignored due to path filters (1)
yarn.lockis excluded by!**/yarn.lock,!**/*.lock
📒 Files selected for processing (30)
.gitignore.prettierignoreforce-releasenx.jsonpackage.jsonpackages/changelog-notify/package.jsonpackages/core/package.jsonpackages/docusaurus/package.jsonpackages/e2e-runner/package.jsonpackages/firebase-hosting/package.jsonpackages/gcp-cloud-run/package.jsonpackages/gcp-deployment-manager/package.jsonpackages/gcp-functions/package.jsonpackages/gcp-functions/src/executors/build/build.impl.tspackages/gcp-functions/src/utils/generate-package-json.tspackages/gcp-secrets/package.jsonpackages/gcp-storage/package.jsonpackages/gcp-task-runner/package.jsonpackages/github-pages/package.jsonpackages/playwright/package.jsonpackages/pulumi/package.jsonpackages/react-email/package.jsonpackages/shadcn-ui/package.jsonpackages/shadcn-ui/src/generators/init/init.impl.tspackages/strapi/package.jsonpackages/terraform/package.jsonpackages/translations/package.jsonpackages/translations/src/plugins/plugin.tspackages/vercel/package.jsonpackages/vercel/src/executors/build/build.impl.ts
| "jest": "30.3.0", | ||
| "jest-environment-jsdom": "30.4.1", | ||
| "jest-util": "30.4.1", |
There was a problem hiding this comment.
🩺 Stability & Availability | 🟠 Major
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
python - <<'PY'
import json
from pathlib import Path
pkg = json.loads(Path("package.json").read_text())
print("repo devDependencies:")
for name in ["jest", "jest-environment-jsdom", "jest-util"]:
print(f" {name}: {pkg['devDependencies'].get(name)}")
PY
python - <<'PY'
import json, urllib.request
for name, version in [
("jest", "30.3.0"),
("jest-environment-jsdom", "30.4.1"),
("jest-util", "30.4.1"),
]:
with urllib.request.urlopen(f"https://registry.npmjs.org/{name}/{version}") as r:
meta = json.load(r)
deps = {k: v for k, v in meta.get("dependencies", {}).items() if "jest" in k.lower()}
print(f"\n{name}@{version}")
print("peerDependencies:", meta.get("peerDependencies"))
print("jest-related dependencies:", deps)
PYRepository: TriPSs/nx-extend
Length of output: 2838
Align the Jest package versions.
jest is pinned to 30.3.0, while jest-environment-jsdom and jest-util are at 30.4.1. Core Jest ecosystem packages rely on strict version alignment for internal APIs and serialization. Mismatched minor versions can cause runtime failures. Update jest to 30.4.1.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@package.json` around lines 53 - 55, The Jest dependencies are out of sync,
with jest pinned to an older version than jest-environment-jsdom and jest-util,
so update the jest package in package.json to match the same 30.4.1 version used
by the other Jest ecosystem packages; keep the versions aligned across the Jest
entries to avoid internal API mismatches.
| import { ExecutorContext, runExecutor } from '@nx/devkit' | ||
| import webpackExecutor, { WebpackExecutorEvent } from '@nx/webpack/dist/src/executors/webpack/webpack.impl' |
There was a problem hiding this comment.
🩺 Stability & Availability | 🟠 Major
Reference the webpack executor by its public ID rather than importing internal implementation details.
The current import of webpackExecutor from @nx/webpack/dist/src/executors/webpack/webpack.impl accesses a private internal path that is blocked by Nx 23's strict exports map. This will cause resolution failures in the published @nx-extend/gcp-functions:build executor after upgrading to Nx 23, as direct access to dist/src files is no longer supported.
Replace this direct import with a programmatic invocation using runExecutor from @nx/devkit and the public executor specifier @nx/webpack:webpack. If type definitions are required, import WebpackExecutorOptions (or the relevant schema type) directly from @nx/webpack if available, or remove the type dependency by inferring types from the executor output stream.
Recommended correction
import { ExecutorContext, runExecutor } from '`@nx/devkit`'
// Remove: import webpackExecutor, { WebpackExecutorEvent } from '`@nx/webpack/dist/src/executors/webpack/webpack.impl`'
// Instead of calling the implementation function directly:
// const result = await webpackExecutor(options);
// Invoke via the public API:
// const results = await runExecutor({ project: 'project', target: 'build', configuration: '' }, options, context);🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@packages/gcp-functions/src/executors/build/build.impl.ts` around lines 1 - 2,
The build executor currently imports webpackExecutor from an internal
`@nx/webpack` dist path, which will break under Nx 23’s exports restrictions.
Update the build.impl.ts executor to use the public `@nx/webpack`:webpack target
through runExecutor from `@nx/devkit` instead of calling the internal
implementation directly, and adjust any WebpackExecutorEvent/type usage to rely
on public types or inferred executor output so the
`@nx-extend/gcp-functions`:build executor remains compatible.
1 participant
Summary by CodeRabbit