nx Typescript generator "Cannot use import statement outside a module"

Sieabah commented 11 months ago

Documentation issue

[ ] Reporting a typo
[ X ] Reporting a documentation bug
[ ] Documentation improvement
[ ] Documentation feedback

Is there a specific documentation page you are reporting?

https://nx.dev/extending-nx/recipes/local-generators

Additional context or description

Run the commands as specified in the page and it just doesn't work when you try to execute the generator.

nx generate @myorg/my-plugin:db-migration mylib

src/generators/db-migration/generator.ts:1
import {
^^^^^^

SyntaxError: Cannot use import statement outside a module
    at internalCompileFunction (node:internal/vm:73:18)
    at wrapSafe (node:internal/modules/cjs/loader:1176:20)
    at Module._compile (node:internal/modules/cjs/loader:1218:27)
    at Module._compile (/Users/myuser/IdeaProjects/<proj folder>/node_modules/pirates/lib/index.js:117:24)
    at Module._extensions..js (node:internal/modules/cjs/loader:1308:10)
    at Object.newLoader [as .ts] (/Users/myuser/IdeaProjects/<proj folder>/node_modules/pirates/lib/index.js:121:7)
    at Module.load (node:internal/modules/cjs/loader:1117:32)
    at Function.Module._load (node:internal/modules/cjs/loader:958:12)
    at Module.require (node:internal/modules/cjs/loader:1141:19)
    at Module.Mod.require (/Users/myuser/IdeaProjects/<proj folder>/node_modules/nx/bin/init-local.js:207:36)

No matter what I do regarding the package json, tsconfig, project.json, or whatever will make this error go away.

✗ node -v
v18.14.2
✗ npm -v     
9.5.0

✗ nx --version
Nx Version:
- Local: v16.9.0
- Global: v16.10.0

Also upgraded everything to 16.10.0 and it still fails to execute.

I understand this is an issue due to the top minds at Node really wanting to emphasize a Python 2/3-like split and have things break. Is my only option to downgrade to node 16 as the docs have a callout specifically for node16? Considering it is now EOL this past September that doesn't seem like the right solution.

Nx uses the paths from tsconfig.base.json when running plugins locally, but uses the recommended tsconfig for node 16 for other compiler options. See https://github.com/tsconfig/bases/blob/main/bases/node16.json

AgentEnder commented 11 months ago

Hey, this is an interesting issue. Are you using npm workspaces or similar by any chance? The reference to node 16 in the docs shouldn't be relevant, this is mainly just to tell folks that setting module type in their tsconfigs doesn't have an effect on how we run local plugins.

Sieabah commented 11 months ago

@AgentEnder

I used nx to generate this project and to manage adding all apps and libs. My root package.json doesn't have anything in it besides a private designation and the packages I'm using.

My nx.json is

{
  "$schema": "./node_modules/nx/schemas/nx-schema.json",
  "tasksRunnerOptions": {
    "default": {
      "runner": "nx/tasks-runners/default",
      "options": {
        "cacheableOperations": ["build", "lint", "test", "e2e"]
      }
    }
  },
  "targetDefaults": {
    "build": {
      "dependsOn": ["^build"],
      "inputs": ["production", "^production"]
    },
    "test": {
      "inputs": ["default", "^production", "{workspaceRoot}/jest.preset.js"]
    },
    "lint": {
      "inputs": [
        "default",
        "{workspaceRoot}/.eslintrc.json",
        "{workspaceRoot}/.eslintignore",
        "{workspaceRoot}/eslint.config.js"
      ]
    },
    "e2e": {
      "inputs": ["default", "^production"]
    }
  },
  "namedInputs": {
    "default": ["{projectRoot}/**/*", "sharedGlobals"],
    "production": [
      "default",
      "!{projectRoot}/**/?(*.)+(spec|test).[jt]s?(x)?(.snap)",
      "!{projectRoot}/tsconfig.spec.json",
      "!{projectRoot}/jest.config.[jt]s",
      "!{projectRoot}/src/test-setup.[jt]s",
      "!{projectRoot}/test-setup.[jt]s",
      "!{projectRoot}/.eslintrc.json",
      "!{projectRoot}/eslint.config.js"
    ],
    "sharedGlobals": []
  },
  "generators": {
    "@nx/angular:application": {
      "style": "scss",
      "linter": "eslint",
      "unitTestRunner": "jest",
      "e2eTestRunner": "playwright"
    },
    "@nx/angular:library": {
      "linter": "eslint",
      "unitTestRunner": "jest"
    },
    "@nx/angular:component": {
      "style": "scss"
    }
  }
}

Sieabah commented 11 months ago

@AgentEnder Are you able to replicate the issue?

Alain00 commented 11 months ago

+1 same issue here

✗ node -v
v16.15.0
✗ npm -v
8.5.5
✗ nx --version                                    
15.0.0

Used nx to generate the whole workspace

Trying to execute the generetor with

nx g domain test-domain -a backend --verbose

I'm getting this error

>  NX   Cannot use import statement outside a module

.../libs/workspace/src/generators/domain/generator.ts:82
import { formatFiles, generateFiles, getWorkspaceLayout, names, offsetFromRoot } from "@nrwl/devkit";
^^^^^^

SyntaxError: Cannot use import statement outside a module
    at new Script (node:vm:100:7)
    at NativeCompileCache._moduleCompile (/home/alain/Projects/contapp/contapp-backend/node_modules/nx/node_modules/v8-compile-cache/v8-compile-cache.js:240:18)
    at Module._compile (/home/alain/Projects/contapp/contapp-backend/node_modules/nx/node_modules/v8-compile-cache/v8-compile-cache.js:184:36)
    at Module._compile (/home/alain/Projects/contapp/contapp-backend/node_modules/pirates/lib/index.js:117:24)
    at Module._extensions..js (node:internal/modules/cjs/loader:1159:10)
    at Object.newLoader [as .ts] (/home/alain/Projects/contapp/contapp-backend/node_modules/pirates/lib/index.js:121:7)
    at Module.load (node:internal/modules/cjs/loader:981:32)
    at Function.Module._load (node:internal/modules/cjs/loader:822:12)
    at Module.require (node:internal/modules/cjs/loader:1005:19)
    at require (/home/alain/Projects/contapp/contapp-backend/node_modules/nx/node_modules/v8-compile-cache/v8-compile-cache.js:159:20)

flippidippi commented 11 months ago

Same here. This is preventing us from upgrading.

quincarter commented 11 months ago

yep i am having this same issue going from 15 to 16.x.x or even beyond to 17.x.x

package manager

yarn 1.x.x

Node Version

Fails no matter what node version i am on.

node -v
16.15.0

node -v 
18.17.1

it had an error on the initial migration but i reran it and it passed

Could not replace @nrwl/linter with @nx/linter in tools/workspace-plugin/src/generators/web-component-ts/files/package.json.
Ran update-16-0-0-add-nx-packages from @nrwl/linter
  Replace @nrwl/linter with @nx/linter

  UPDATE package.json
  UPDATE .nx/cache/file-map.json
  UPDATE .nx/cache/parsed-lock-file.json
  UPDATE .nx/cache/project-graph.json
  UPDATE migrations.json
---------------------------------------------------------
thread '<unnamed>' panicked at 'called `Result::unwrap()` on an `Err` value: Os { code: 2, kind: NotFound, message: "No such file or directory" }', packages/nx/src/native/plugins/js/ts_import_locators.rs:450:10
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
thread '<unnamed>' panicked at 'called `Result::unwrap()` on an `Err` value: Os { code: 2, kind: NotFound, message: "No such file or directory" }', packages/nx/src/native/plugins/js/ts_import_locators.rs:450:10
thread '<unnamed>' panicked at 'called `Result::unwrap()` on an `Err` value: Os { code: 2, kind: NotFound, message: "No such file or directory" }', packages/nx/src/native/plugins/js/ts_import_locators.rs:450:10
thread '<unnamed>' panicked at 'called `Result::unwrap()` on an `Err` value: Os { code: 2, kind: NotFound, message: "No such file or directory" }thread '', <unnamed>' panicked at 'called `Result::unwrap()` on an `Err` value: Os { code: 2, kind: NotFound, message: "No such file or directory" }', packages/nx/src/native/plugins/js/ts_import_locators.rs:450:10
thread '<unnamed>' panicked at 'called `Result::unwrap()` on an `Err` value: Os { code: 2, kind: NotFound, message: "No such file or directory" }', packages/nx/src/native/plugins/js/ts_import_locators.rs:450:10
thread 'thread '<unnamed>' panicked at 'called `Result::unwrap()` on an `Err` value: Os { code: 2, kind: NotFound, message: "No such file or directory" }', packages/nx/src/native/plugins/js/ts_import_locators.rs<unnamed>' panicked at 'called `Result::unwrap()` on an `Err` value: Os { code: 2, kind: NotFound, message: "No such file or directory" }', thread 'packages/nx/src/native/plugins/js/ts_import_locators.rs<unnamed>:thread '<unnamed>' panicked at 'called `Result::unwrap()` on an `Err` value: Os { code: 2, kind: NotFound, message: "No such file or directory" }', packages/nx/src/native/plugins/js/ts_import_locators.rs:thread '450:10<unnamed>thread '450' panicked at '<unnamed>:called `Result::unwrap()` on an `Err` value: Os { code: 2, kind: NotFound, message: "No such file or directory" }', packages/nx/src/native/plugins/js/ts_import_locators.rs' panicked at ':450:10
10
called `Result::unwrap()` on an `Err` value: Os { code: 2, kind: NotFound, message: "No such file or directory" }', packages/nx/src/native/plugins/js/ts_import_locators.rs:450:10
:450:10
thread '<unnamed>' panicked at 'called `Result::unwrap()` on an `Err` value: Os { code: 2, kind: NotFound, message: "No such file or directory" }', packages/nx/src/native/plugins/js/ts_import_locators.rs:450:10
thread '<unnamed>' panicked at 'called `Result::unwrap()` on an `Err` value: Os { code: 2, kind: NotFound, message: "No such file or directory" }', packages/nx/src/native/plugins/js/ts_import_locators.rs:450:10
thread '<unnamed>' panicked at 'called `Result::unwrap()` on an `Err` value: Os { code: 2, kind: NotFound, message: "No such file or directory" }', packages/nx/src/native/plugins/js/ts_import_locators.rs:450:10
thread '<unnamed>' panicked at 'called `Result::unwrap()` on an `Err` value: Os { code: 2, kind: NotFound, message: "No such file or directory" }', packages/nx/src/native/plugins/js/ts_import_locators.rs:450:10thread '
<unnamed>' panicked at 'called `Result::unwrap()` on an `Err` value: Os { code: 2, kind: NotFound, message: "No such file or directory" }', packages/nx/src/native/plugins/js/ts_import_locators.rs:450:10
packages/nx/src/native/plugins/js/ts_import_locators.rs:450:10
' panicked at 'called `Result::unwrap()` on an `Err` value: Os { code: 2, kind: NotFound, message: "No such file or directory" }', packages/nx/src/native/plugins/js/ts_import_locators.rs:450:10

fatal runtime error: failed to initiate panic, error 5
error Command failed with signal "SIGABRT".
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.
Command failed: yarn nx _migrate --run-migrations
error Command failed with exit code 1.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.

 >  NX   Command failed: yarn nx migrate --run-migrations

   Pass --verbose to see the stacktrace.

Failed.generate command

$ nx generate web-component-ts $1 test-here --verbose

>  NX  Generating workspace-plugin:web-component-ts

✔ Which type of library would you like to generate? · component

 >  NX   Cannot use import statement outside a module

......./tools/workspace-plugin/src/generators/web-component-ts/index.ts:1
import {
^^^^^^

SyntaxError: Cannot use import statement outside a module
    at Object.compileFunction (node:vm:352:18)
    at wrapSafe (node:internal/modules/cjs/loader:1033:15)
    at Module._compile (node:internal/modules/cjs/loader:1069:27)
    at Module._compile (......./node_modules/pirates/lib/index.js:136:24)
    at Module._extensions..js (node:internal/modules/cjs/loader:1159:10)
    at Object.newLoader [as .ts] (......./node_modules/pirates/lib/index.js:141:7)
    at Module.load (node:internal/modules/cjs/loader:981:32)
    at Function.Module._load (node:internal/modules/cjs/loader:822:12)
    at Module.require (node:internal/modules/cjs/loader:1005:19)
    at Module.Mod.require (......./node_modules/nx/bin/init-local.js:207:36)
error Command failed with exit code 1.

feel free to fork this (it's in gitlab, not github) and you can try to replicate it. Component Library Starter node version 16.16.x or above run the nx migrate commands to go to latest or 16.x.x I am also running yarn locally

npm script to execute the generator is:

yarn new-component:ts test-test-test

quincarter commented 11 months ago

update - at work i am on nx 16.9.1 and i just tried to create a generator following these docs and it has the same result. So it looks like the issue may be unrelated to the update for me. What is the file tree missing?

quincarter commented 11 months ago

When i run it, this is where the error happens (same place as before, so the entrypoint to the generator?)

import { // error happens here in all instances
  addProjectConfiguration,
  formatFiles,
  generateFiles,
  Tree,
} from '@nx/devkit';
import * as path from 'path';
import { MyGeneratorGeneratorSchema } from './schema';

antoinepairet commented 11 months ago

@AgentEnder We are also impacted by this issue.

"executor": "@org/projectName:executorName"

works in Nx16
is broken in Nx17 - the error will be NX Cannot use import statement outside a module

"executor": "./dist/outputPathOfProject:executorName"

works in both Nx16 and Nx17

To summarize: in Nx17 we have to build our executors first and then we can use them by pointing to the dist folder.

@AgentEnder Let me know if you need a full reproduction repo. Happy to provide one if needed.

AgentEnder commented 11 months ago

A reproduction would certainly help, thanks for the offer.

antoinepairet commented 11 months ago

It took me some time to figure it out:

The issue occurs when tsconfig.base.ts has a files property
Nx 16.8.1 is NOT impacted
Nx 16.10.0 and Nx 17 are impacted

I created a repo with three branches illustrating the different behaviors: https://github.com/rosahealth/nx-17-local-executor-tsconfig-bug/branches/all

The command to run is npx nx run myngapp:bug-local-executor --skip-nx-cache On 16.8.1, it succeeds. While 16.10 and 17 have the following error:

 >  NX   Cannot use import statement outside a module

Commit from the Nx 17 that makes it crash: https://github.com/rosahealth/nx-17-local-executor-tsconfig-bug/commit/c15ca6889c4b1e64b5ec8933bb413db4c4fa4b34

The content of the files array does not matter. What matters is having the property defined.

@AgentEnder Let me know if I can help further on this topic.

antoinepairet commented 11 months ago

The issue also occurs when the property include is set.

quincarter commented 11 months ago

Can confirm that 16.9.1 is not impacted - just ran migrations from 15 to that version and my generate commands are working as of right now. but when i go beyond that version into the ^16.10.x || ^17.x.x range, it fails with the error mentioned in this issue.

quincarter commented 11 months ago

Alright so i got the error to happen on 16.9.1. I think there is something up with the @swc-node/register package on the latest version (1.6.8). I have literally every other package on my repo updated to latest (except the nrwl packages, i stayed on 16.9.1).

Any package in the `@swc-node/register` 1.6.x range

Throws the import error listed in this ticket.

Any `@swc-node/register` in the 1.5.x range

Any package using 1.5.x will throw this error (which i have seen in my migration script before, seen above).

Working version of `@swc-node/register` is 1.4.x

When i use 1.4.2 it appears to function without the import error or the panic error

I will attempt to update to 17.x.x and see if it still has errors but this is promising.

quincarter commented 11 months ago

Can confirm. Upgraded every package in my repo and ran the nx 17 migration to latest. It updated @swc-node/register to latest in the migration (1.6.8). I downgraded it back to 1.4.2 and nx generate commands appear to be working for me.

Here is my dependency tree for those that want to see the versions.

{
  "dependencies": {
    "@changesets/cli": "^2.26.2",
    "@swc/helpers": "~0.5.3",
    "lit": "^3.0.0"
  },
  "devDependencies": {
    "@angular-devkit/schematics": "^16.2.8",
    "@babel/core": "^7.23.2",
    "@babel/preset-env": "^7.23.2",
    "@babel/preset-react": "^7.22.15",
    "@babel/preset-typescript": "^7.23.2",
    "@custom-elements-manifest/analyzer": "^0.9.0",
    "@nx/devkit": "17.0.2",
    "@nx/eslint-plugin": "17.0.2",
    "@nx/jest": "17.0.2",
    "@nx/js": "17.0.2",
    "@nx/plugin": "17.0.2",
    "@nx/workspace": "17.0.2",
    "@open-wc/eslint-config": "^12.0.1",
    "@open-wc/testing": "latest",
    "@storybook/addon-actions": "^7.5.1",
    "@storybook/addon-cssresources": "^6.2.9",
    "@storybook/addon-essentials": "^7.5.1",
    "@storybook/addon-links": "^7.5.1",
    "@storybook/addon-mdx-gfm": "^7.5.1",
    "@storybook/builder-vite": "^7.5.1",
    "@storybook/web-components": "^7.5.1",
    "@storybook/web-components-vite": "^7.5.1",
    "@storybook/web-components-webpack5": "^7.5.1",
    "@swc-node/register": "1.4.2", // just note that this is downgraded and hard-versioned to 1.4.2
    "@swc/cli": "~0.1.62",
    "@swc/core": "~1.3.95",
    "@types/jest": "29.5.6",
    "@types/node": "latest",
    "@typescript-eslint/eslint-plugin": "^6.9.0",
    "@typescript-eslint/parser": "^6.9.0",
    "@web/dev-server": "^0.3.6",
    "@web/dev-server-storybook": "next",
    "@web/test-runner": "^0.17.2",
    "babel-loader": "^9.1.3",
    "babel-plugin-template-html-minifier": "^4.1.0",
    "concurrently": "^8.2.2",
    "eslint": "^8.52.0",
    "eslint-config-prettier": "9.0.0",
    "eslint-plugin-storybook": "^0.6.15",
    "husky": "^8.0.3",
    "jest": "29.7.0",
    "jest-environment-jsdom": "29.7.0",
    "lint-staged": "^15.0.2",
    "nx": "17.0.2",
    "prettier": "^3.0.3",
    "react": "^18.2.0",
    "react-dom": "^18.2.0",
    "rimraf": "^5.0.5",
    "storybook": "^7.5.1",
    "storybook-readme": "^5.0.9",
    "ts-jest": "29.1.1",
    "ts-node": "10.9.1",
    "tslib": "^2.6.2",
    "typescript": "5.2.2",
    "vite": "^4.5.0",
    "web-component-analyzer": "^2.0.0",
    "@nx/eslint": "17.0.2"
  }
}

quincarter commented 11 months ago

i wrote up a quick article outlining this on dev.to if you all would like to read it. But it just basically has my findings i listed in these comments. Share this with others if this ends up being a fix that works for people.

https://dev.to/quincarter/nx-17-upgrade-errors-cannot-use-import-outside-a-module-1ea8

quincarter commented 11 months ago

@AgentEnder - i am not sure if there are any vulnerabilities in the @swc-node/register@1.4.2 package, or what the risks are for downgrading it, but That does seem to work and it looks like all of my commands that are nx related seem to be working right now in my project. Not sure if others can confirm here. Maybe @Sieabah or @antoinepairet can confirm?

antoinepairet commented 11 months ago

@quincarter Forcing the usage of @swc-node/register@1.4.2 solves the issue. Here is a new branch with the change: https://github.com/rosahealth/nx-17-local-executor-tsconfig-bug/tree/nx-16-10-0-with-swc-node-1-4-2

Installing @swc-node/register@1.4.2 requires --force because of peerDependency conflicts:

➜  myngapp git:(nx-16-10-0) ✗ npm i --force
npm WARN using --force Recommended protections disabled.
npm WARN ERESOLVE overriding peer dependency
npm WARN While resolving: nx@16.10.0
npm WARN Found: @swc-node/register@1.4.2
npm WARN node_modules/@swc-node/register
npm WARN   dev @swc-node/register@"1.4.2" from the root project
npm WARN 
npm WARN Could not resolve dependency:
npm WARN peerOptional @swc-node/register@"^1.6.7" from nx@16.10.0
npm WARN node_modules/nx
npm WARN   dev nx@"16.10.0" from the root project
npm WARN   3 more (@nx/devkit, @nx/workspace, @nrwl/tao)
npm WARN 
npm WARN Conflicting peer dependency: @swc-node/register@1.6.8
npm WARN node_modules/@swc-node/register
npm WARN   peerOptional @swc-node/register@"^1.6.7" from nx@16.10.0
npm WARN   node_modules/nx
npm WARN     dev nx@"16.10.0" from the root project
npm WARN     3 more (@nx/devkit, @nx/workspace, @nrwl/tao)

quincarter commented 11 months ago

Ah ok so I didn't get that with yarn due to dependency hoisting. Npm is good to mention that you had to force it.

Sieabah commented 10 months ago

Trying to install that version on my setup causes npm to spin into an infinite loop telling me it can't meet peer deps, even when it's forced to. Have to open up a separate terminal just to kill the install process.

I couldn't copy the text because it was filling the terminal too quickly.

Pretty intense install for sure. This is on node 18.18.2 with npm 9.8.1. Sonoma 14.0.

For now, I'm just not going to be using nx generators as they're just too much trouble with typescript, maybe npm scripts and yeoman if that's still used these days.

AgentEnder commented 10 months ago

Looking into this more. Can anyone provide the use case for having files / includes in tsconfig.base.json? I can see how that is causing the problem in newer versions of swc-node.

You can set NX_PREFER_TS_NODE to tell Nx to use it instead, which should avoid this altogether while we work on it.

Sieabah commented 10 months ago

@AgentEnder I was using 'includes' to ensure my migration files were bundled without having to manually specify each file as an import in some file.

AgentEnder commented 10 months ago

@Sieabah, can you grab the outputs of npx tree-cli -l 3 --ignore=tools,tmp? I'm trying to better understand the layout of your workspace where this would make sense

Sieabah commented 10 months ago

I have base migrations that are shared per-project in:

core-server/database/migrations
- In this folder are general migrations dated by time.
apps/app-*/database/migrations/
- Application specific migrations exists in these folders.

I use knex and just point it to the folders, but because there is a build step with typescript the files are not automatically compiled and results with 0 migrations if I don't somehow include them manually.

Since this is not supported with NX I just tore out all of that and manually imported every migration and ran it with a custom migration source. I'm importing some 20-30 files in a throwaway file, it's not great but it works...

AgentEnder commented 10 months ago

Ah, I see - I had interpreted it as plugin migrations, not database migrations so I was a bit confused. I think I would probably recommend something like creating a tsconfig.app.json at the root, which extends the tsconfig.base.json and has the files declarations on it, which is then what your app tsconfigs can extend as needed.

Still a bit clunky, but I think its better than adding them to the tsconfig.base.json

flippidippi commented 10 months ago

We were able to upgrade by moving tsconfig.base.json "files" into only the tsconfigs that need it. Which we probably should have had it that way to start, but I was lazy 😄

AgentEnder commented 10 months ago

I'm still working on formulating the exact fix we want to go with here, I'm personally leaning towards dropping @swc-node/register as a supported transpiler. Its not that much faster than ts-node, and this isn't the first time we've hit an issue with it.

CSchulz commented 9 months ago

We were able to upgrade by moving tsconfig.base.json "files" into only the tsconfigs that need it. Which we probably should have had it that way to start, but I was lazy 😄

Can you explain your solution more in detail, please? I have the same issue, after removing the files property from the tsconfig.base.json I have issues with resolving a tsconfig path.

"@app/tools-i18n-extractor": ["tools/i18n-extractor/main.ts"],

My solution for that is following:

//import { main } from '@app/tools-i18n-extractor'
import { main } from 'tools/i18n-extractor/main'

joeldbirch commented 8 months ago

My team has been trying to workaround this for a while now. We've tried setting the version of @swc-node/register to "1.4.2" as per this comment which works but it seems like NX (or … something) keeps editing the package.json to point back to "^1.6.7". Our team hasn't pin-pointed what causes this. Does anyone have an idea as to why/how this could happen please?

quincarter commented 8 months ago

My team has been trying to workaround this for a while now. We've tried setting the version of @swc-node/register to "1.4.2" as per this comment which works but it seems like NX (or … something) keeps editing the package.json to point back to "^1.6.7". Our team hasn't point-pointed what causes this. Does anyone have an idea as to why/how this could happen please?

Pretty sure this happens as a result of the nx migrate process. When I run that on my repos I just have to remember to change it back to the earlier version. It works. It's a hack. I still haven't found a better solution.

joeldbirch commented 8 months ago

@quincarter thanks for the suggestion, but we haven't manually run that and the package.json change is still constantly sneaking back into our commits.

Sieabah commented 8 months ago

@joeldbirch Make a git commit hook which enforces the version.

phil-hudson-aon commented 7 months ago

My team has been trying to workaround this for a while now. We've tried setting the version of @swc-node/register to "1.4.2" as per this comment which works but it seems like NX (or … something) keeps editing the package.json to point back to "^1.6.7". Our team hasn't pin-pointed what causes this. Does anyone have an idea as to why/how this could happen please?

this resolved the issue for me as well.

JulianMar commented 7 months ago

This version of @swc-node/register is not compatible with nx 18 anymore. https://github.com/nrwl/nx/blob/master/package.json#L107 A real fix here would be highly appreciated.

quincarter commented 7 months ago

This version of @swc-node/register is not compatible with nx 18 anymore. https://github.com/nrwl/nx/blob/master/package.json#L107 A real fix here would be highly appreciated.

The downgrade does still work I believe. v1.4.2. but that's not a real fix.

AdhamAwadhi commented 6 months ago

I upgraded @swc-node/register to 1.8.0 and it works ok.

eyea commented 5 months ago

same here, even if i upgraded @swc-node/register to 1.8.0

package.json

{
  "name": "@she/source",
  "version": "0.0.0",
  "license": "MIT",
  "scripts": {},
  "private": true,
  "dependencies": {
    "next": "14.0.4",
    "react": "18.2.0",
    "react-dom": "18.2.0",
    "react-router-dom": "5.3.4",
    "styled-components": "5.3.3",
    "tslib": "^2.3.0"
  },
  "devDependencies": {
    "@afuteam-nx/plugin-fetch-repos": "^0.0.5",
    "@nx-extend/strapi": "^9.0.2",
    "@nx/eslint": "18.2.3",
    "@nx/eslint-plugin": "18.2.3",
    "@nx/jest": "18.2.3",
    "@nx/js": "18.2.3",
    "@nx/next": "18.2.3",
    "@nx/workspace": "18.2.3",
    "@swc-node/register": "~1.8.0",
    "@swc/core": "~1.3.85",
    "@swc/helpers": "~0.5.2",
    "@types/jest": "^29.4.0",
    "@types/node": "18.16.9",
    "@types/react": "18.2.33",
    "@types/react-dom": "18.2.14",
    "@typescript-eslint/eslint-plugin": "^7.3.0",
    "@typescript-eslint/parser": "^7.3.0",
    "babel-jest": "^29.4.1",
    "eslint": "~8.57.0",
    "eslint-config-next": "14.0.4",
    "eslint-config-prettier": "^9.0.0",
    "eslint-plugin-import": "2.27.5",
    "eslint-plugin-jsx-a11y": "6.7.1",
    "eslint-plugin-react": "7.32.2",
    "eslint-plugin-react-hooks": "4.6.0",
    "jest": "^29.4.1",
    "jest-environment-jsdom": "^29.4.1",
    "nx": "18.2.3",
    "prettier": "^2.6.2",
    "ts-jest": "^29.1.0",
    "ts-node": "10.9.1",
    "typescript": "~5.4.2"
  }
}

tsconfig.base.json

{
  "compileOnSave": false,
  "compilerOptions": {
    "rootDir": ".",
    "sourceMap": true,
    "declaration": false,
    "moduleResolution": "node",
    "emitDecoratorMetadata": true,
    "experimentalDecorators": true,
    "importHelpers": true,
    "target": "es2015",
    "module": "esnext",
    "lib": ["es2020", "dom"],
    "skipLibCheck": true,
    "skipDefaultLibCheck": true,
    "baseUrl": ".",
    "paths": {}
  },
  "exclude": ["node_modules", "tmp"]
}

maybe the plugin's error ? I'm not sure, @afuteam-nx/plugin-fetch-repos btw, this plugin is published according the docs: extending-nx/tutorials/publish-plugin

t-mish commented 2 months ago

Still relevant. swc-node/register needs to be downgraded to 1.4.2 to work with the latest Nx 19.4.3

tommoyang commented 4 weeks ago

I've run into this issue as well, albeit it manifests slightly differently:

Currently up to nx@18.2.3, I have a project with a generator that works fine on @swc-node/register@1.8.0.

Attempting to upgrade further (nx@18.3.0 or higher) causes the generator to fail in the same way as listed in the issue. Neither upgrading nor downgrading @swc-node/register resolves the error

wcwcaseman commented 3 days ago

I have this issue during our build, once I upgrade to nx version 16.10 or 17 from 16.9.1. If I leave @swc-node/register at 1.4.2 I get the error mentioned. If I leave it at 1.6.7 I get "Cannot read properties of undefined (reading 'resolve')."because I use path to combine a path i'm trying to load. Then If I update to the latest "@swc-node/register": "1.10.9" I get the error Cannot find module for the path i'm importing using require(path);.

Also I do not have this issue on NX 16.9.1 even after upgrading @swc-node/register to 1.6.7 on that version. One of the updates in 16.10.0 should be undone. For me this is preventing my team from upgrading beyond 16.9.1. I would love to see fix for this issue.

nrwl / nx