POC: Identify Changes Required for Unified Nx Workspace at Repo Root

Research Question

The repo has four independent Node workloads (core-web, dotcms-postman, dotcms-e2e-node, dotcms-ui-e2e) each with isolated node_modules, separate yarn.lock, and no shared build intelligence. This spike investigates what changes are required to establish a single Nx workspace at the repo root, unifying all Node workloads under one package.json, one yarn.lock, and one Nx project graph — and whether the migration is feasible in a phased approach.

Additionally, some Node Maven modules use workingDirectory parameters referencing directories outside their own module boundary (e.g., workingDirectory: ./frontend in dotcms-e2e-node/pom.xml), violating Maven's module independence principle. Maven has no way to express source-level filesystem dependencies — these references are invisible to the build graph and silently break when directories change.

The goal of this POC is to identify the full scope of changes required before committing to the migration.

Timebox

8h

Acceptance Criteria

• Document all files that need to change (pom.xml files, tsconfig paths, project.json refs, CI working directories, .husky paths)
• Confirm whether e2e/dotcms-e2e-node is superseded by dotcms-ui-e2e (coordinate with Arcadio/frontend team) — affects migration scope
• Evaluate feasibility of adding Node to .mise.toml to retire nodejs-parent as a standalone quick win (independent of full migration)
• Assess risk of moving nx.json and tsconfig.base.json to repo root — identify which path aliases and project references break
• Identify the lowest-risk stepping stone: root package.json + Yarn workspaces pointing at existing module directories (shared node_modules without moving nx.json)
• Document the Husky v7→v9 upgrade path and confirm .husky/ can move to repo root as a standalone change
• Produce a phased migration plan with clear go/no-go criteria per phase

Context

Current fragmentation — four isolated Node workloads:

Maven independence violation:

<!-- e2e/dotcms-e2e-node/pom.xml reaches into ./frontend -->
<workingDirectory>./frontend</workingDirectory>  ← source not owned by this pom.xml ❌

Husky workaround (current core-web/package.json):

"prepare": "cd .. && node core-web/prepare.js"

Husky v7 requires hooks wired at git root — the prepare script explicitly navigates out of core-web/ to reach the repo root. Definition and registration locations disagree. Java developers using targeted builds (just build-quicker) never trigger this install and have no pre-commit hooks.

Target structure (post-migration):

repo-root/
├── nx.json                    ← moved from core-web/
├── tsconfig.base.json         ← single shared TS path aliases
├── package.json               ← single root package, workspaces config
├── yarn.lock                  ← single lockfile for all Node workloads
├── core-web/apps/dotcms-ui/   ← Angular app (unchanged internally)
├── e2e/dotcms-ui-e2e/         ← Playwright E2E (self-contained, own pom.xml)
└── postman/dotcms-postman/    ← Newman (self-contained, own pom.xml)

Proposed stepping stones:

1. Deprecate e2e/dotcms-e2e-node if superseded — reduces scope
2. Add node = "22.15.0" to .mise.toml → retire nodejs-parent (standalone, independent of migration)
3. Move .husky/ to repo root + upgrade to Husky v9 (standalone quick win)
4. Add root package.json + Yarn workspaces → shared node_modules without moving nx.json
5. Move nx.json + tsconfig.base.json to repo root → full unified workspace

Links

• PR #33266 (dotcms-ui-e2e): https://github.com/dotCMS/core/pull/33266
• Issue #34753 (GHA caching): https://github.com/dotCMS/core/issues/34753
• nodejs-parent/pom.xml — installs Node v22.15.0, Yarn v1.22.19
• .mise.toml at repo root — already manages gh, python, actionlint, shellcheck; Node not yet declared
• Context owners: Steve Bolton (Enablement), Arcadio Quintero (dotcms-ui-e2e author), Frontend platform team

Start by inventorying the named pom.xml files, .mise.toml, core-web/package.json, nx.json, tsconfig.base.json, project.json references, CI working directories, and .husky paths. Trace the existing module boundaries and path aliases, then document the affected files, migration risks, stepping stones, and go/no-go criteria, including whether dotcms-e2e-node is superseded.