36540 nx replace deprecated nxvitetspaths plugin with vite tsconfig paths in core web by nicobytes · Pull Request #36575 · dotCMS/core

nicobytes · 2026-07-14T16:14:04Z

Summary

Replaces the deprecated nxViteTsPaths and nxCopyAssetsPlugin (from @nx/vite) with their
standalone equivalents ahead of the Nx v24 removal, across the four affected vite.config files
in core-web (edit-content-bridge, sdk/experiments, sdk/analytics, sdk/vue).

nxViteTsPaths() → tsconfigPaths() from vite-tsconfig-paths. The SDK libs that bundle
sibling sources (experiments, analytics, vue) pass root pointing at the core-web
workspace root, since vite-tsconfig-paths scopes alias resolution by root instead of resolving
globally like the Nx plugin did — without it, @dotcms/* aliases (e.g. @dotcms/types) fail to
resolve inside bundled sibling packages like @dotcms/uve.
nxCopyAssetsPlugin(['*.md']) → viteStaticCopy() from vite-plugin-static-copy in sdk/vue.
Adds vite-tsconfig-paths and vite-plugin-static-copy as dependencies; adds
vite-tsconfig-paths to edit-content-bridge's @nx/dependency-checks ignore list.
Includes an eslint --fix formatting pass over sdk-vue's .vue templates, triggered by the
migration touching that lint task (indentation/attribute-per-line only, no behavior change).

Closes #36540.

Test plan

nx build edit-content-bridge, nx build sdk-experiments, nx build sdk-analytics,
nx build sdk-vue all succeed with no nxViteTsPaths deprecation warning
nx test sdk-vue (vitest) passes — verifies @dotcms/* alias resolution still works from
bundled sources
nx lint edit-content-bridge passes (dependency-checks rule)
Manual smoke: consuming apps that import from @dotcms/uve via these SDKs still resolve
correctly after the bundle change

This PR fixes: #36540

…ivalents (#36540) nxViteTsPaths and nxCopyAssetsPlugin are deprecated and will be removed in Nx v24. Replace them with vite-tsconfig-paths and vite-plugin-static-copy across the four affected vite.config files (edit-content-bridge, sdk/experiments, sdk/vue, sdk/analytics). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

Auto-fix run by the sdk-vue lint task after the vite-tsconfig-paths migration reformatted template indentation (vue/html-indent, vue/max-attributes-per-line) across existing components. No behavior change. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

claude · 2026-07-14T16:15:20Z

Claude finished @nicobytes's task in 2m 32s —— View job

Code Review: Replace deprecated `nxViteTsPaths` with `vite-tsconfig-paths`

Read PR diff against origin/main
Review the 4 migrated vite.config files + standalone config
Check eslint dependency-checks + package.json changes
Verify alias resolution assumptions (tsconfig.base.json, root/projects)

I reviewed the config migration across edit-content-bridge, sdk/experiments, sdk/analytics (+ standalone) and sdk/vue. The mechanics are sound:

tsconfigPaths({ root: <workspace root>, projects: ['tsconfig.base.json'] }) is the right shape — tsconfig.base.json holds all 60 @dotcms/* aliases and pinning projects avoids the monorepo-wide tsconfig crawl. Root depths are correct (../../ for edit-content-bridge, ../../../ for the sdk/* libs).
viteStaticCopy({ targets: [{ src: '*.md', dest: '.' }] }) is an accurate replacement for nxCopyAssetsPlugin(['*.md']) (copies to the build outDir root).
loose: true on the Vue config is correctly justified — tsconfig.base.json has no allowJs, so .vue importers wouldn't resolve @dotcms/* without it.
Dropping buildLibsFromSource: true on edit-content-bridge is safe: tsconfigPaths already resolves @dotcms/* aliases to source via tsconfig.base.json.
Only edit-content-bridge runs @nx/dependency-checks, and its ignore list was correctly updated (@nx/vite → vite-tsconfig-paths); the other SDK libs don't run that rule.
New deps added to core-web/package.json (workspace root), not to a lib package.json — correct.

New Issues

No blocking issues found.

Notes (non-blocking)

🟡 Minor: libs/edit-content-bridge/vite.config.mts:12 — the plugin comment references @dotcms/dotcms-models, @dotcms/ui while the other three configs say @dotcms/types. Cosmetic only; worth aligning for consistency but not required.

The root/projects reasoning is well documented inline and the CI-segfault rationale is captured, which is helpful for future maintainers. Two approvals already in place — LGTM from my pass. Please make sure the Test plan checkboxes (the four nx builds + nx test sdk-vue + nx lint edit-content-bridge) are green before merge, since the correctness of this change lives entirely in the build/test output.
• 36540-nx-replace-deprecated-nxvitetspaths-plugin-with-vite-tsconfig-paths-in-core-web

…ugin-with-vite-tsconfig-paths-in-core-web

- vite.standalone.config.mts (analytics build:standalone target) was missed by the original migration and still used the deprecated nxViteTsPaths plugin. - edit-content-bridge/vite.config.ts now sets root for consistency with the other SDK configs. This surfaced an off-by-one path bug: edit-content-bridge lives two directories below core-web/ (not three, like libs/sdk/*), so '../../../' resolved to the repo root and made tsconfigPaths scan unrelated example projects. Fixed to '../../'. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

This file was already staged from unrelated local work when the previous commit ran and got swept in unintentionally. Removing it here since that directory's fate is still an open question, not part of this PR. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

…ugin-with-vite-tsconfig-paths-in-core-web

…ect graph failure CI has been failing consistently at nx affected -t lint, but Nx swallows the real stack trace for the libs/sdk/experiments/vite.config.ts load error ("Pass --verbose to see the stacktraces"). Local repro attempts (matching Node/pnpm/package versions, cold nx cache, concurrent config loads) all succeed, so this only reproduces on the Linux CI runner. Adding --verbose to get the real error before attempting a targeted fix.

…k-experiments to fix CI-only Node race The verbose stack trace from CI (temporarily enabled via --verbose) revealed the real error masked by "failed to load config": Error [ERR_INTERNAL_ASSERTION]: Cannot require() ES Module vite-tsconfig-paths/dist/index.js because it is not yet fully loaded. This may be caused by a race condition if the module is simultaneously dynamically import()-ed via Promise.all(). Vite bundles plain .ts configs to CJS and loads them via require(), which races with Nx's parallel @nx/vite plugin workers concurrently import()-ing the same ESM-only vite-tsconfig-paths package elsewhere in the same process (@nx/vite's own plugin.js has a similar documented workaround for @vitejs/plugin-vue, but not for vite-tsconfig-paths). This only surfaced on the Linux CI runner with a cold Nx cache and higher worker parallelism - local repro attempts (matching Node/pnpm versions, cold cache, concurrent loads) never hit it. edit-content-bridge and sdk/experiments were the only two vite.config.ts files in the workspace still using the plain .ts (CJS-bundled) extension while importing vite-tsconfig-paths. sdk/vue and sdk/analytics already use .mts and load as native ESM, avoiding the require()/import() race entirely. Renaming these two to .mts (and __dirname -> import.meta.dirname to match) applies the same fix consistently. Reverts the diagnostic --verbose flag added in the previous commit now that the real cause is known.

…CI segfaults Modified vite.config.mts files across multiple libraries to include the `projects` option in the tsconfigPaths plugin. This change ensures that resolution is pinned to the base tsconfig, preventing the plugin from crawling every tsconfig in the monorepo, which previously caused segfaults in CI environments.

…ugin-with-vite-tsconfig-paths-in-core-web

Updated the tsconfigPaths plugin configuration in vite.config.mts to include the `loose: true` option. This change ensures that Vue Single File Components (SFCs) can resolve aliases correctly, preventing import failures for .vue files when using the vite-tsconfig-paths plugin.

…ite-tsconfig-paths-in-core-web' of github.com:dotCMS/core into 36540-nx-replace-deprecated-nxvitetspaths-plugin-with-vite-tsconfig-paths-in-core-web

mergify · 2026-07-15T11:53:34Z

Tick the box to add this pull request to the merge queue (same as @mergifyio queue).

Queue this pull request

…TsPaths removal (dotCMS#36598) ## Summary - Restores explicit `package.json` (and README) copy into `dist` for `@dotcms/analytics` and `@dotcms/vue` via `viteStaticCopy`, replacing a hidden side effect of the removed `nxViteTsPaths()` plugin. - Hardens the SDK NPM publish action to skip `dist` directories that have no `package.json` (e.g. `analytics-standalone`), so the publish loop does not fail with `jq: Could not open file package.json`. ## Context Trunk SDK `@next` publish failed on [run 29416418823](https://github.com/dotCMS/core/actions/runs/29416418823) after [dotCMS#36575](dotCMS#36575) replaced `nxViteTsPaths()` with `vite-tsconfig-paths`. The Nx plugin copied `package.json` into the Vite `outDir` on `writeBundle`; the replacement does not. Publish then crashed while processing `@dotcms/analytics` after partially publishing `ai`, `angular`, and `types` as `1.7.1-next.2363`. ## Test plan - [x] `pnpm exec nx build sdk-analytics --configuration=production` — `dist/libs/sdk/analytics/package.json` present - [x] `pnpm exec nx build sdk-vue --configuration=production` — `dist/libs/sdk/vue/package.json` present - [ ] After merge, next trunk deployment publishes a full coherent `@next` set (new `run_number`; do not re-run 2363) This PR fixes: dotCMS#36540

nicobytes and others added 2 commits July 14, 2026 12:10

nicobytes linked an issue Jul 14, 2026 that may be closed by this pull request

Nx: Replace deprecated nxViteTsPaths and nxCopyAssetsPlugin plugin #36540

Closed

5 tasks

github-project-automation Bot added this to dotCMS - Product Planning Jul 14, 2026

github-actions Bot added Area : Frontend PR changes Angular/TypeScript frontend code Area : SDK PR changes SDK libraries labels Jul 14, 2026