`@nx/dependency-checks` fails to detect dependencies after upgrade to nx 18

[Helveg]

Current Behavior

I upgraded my workspace to nx 18. Linting passed before the upgrade, but after the upgrade @nx/dependency-checks started reporting all my dependencies as obsolete:

C:\Users\pwd06\git\gilbert\packages\ab-resources\package.json
   7:5  error  The "@angular/common" package is not used by "ab-resources" project  @nx/dependency-checks
   8:5  error  The "@angular/core" package is not used by "ab-resources" project    @nx/dependency-checks
   9:5  error  The "chart.js" package is not used by "ab-resources" project         @nx/dependency-checks
  10:5  error  The "date-fns" package is not used by "ab-resources" project         @nx/dependency-checks
  11:5  error  The "deepmerge-ts" package is not used by "ab-resources" project     @nx/dependency-checks

Worthy to note: The dependencies on other libraries in the workspace is still detected, and visible in the project graph with nx graph.

Expected Behavior

These dependencies were detected before, and are imported in the source code, and analyzeSourceFiles is enabled for @nx/js, so I expect them to be detected like in nx@17

GitHub Repo

No response

Steps to Reproduce

Not sure, it might be due to the history of my Nx workspace, willing to follow diagnostic instructions to figure out a reproducer.

Nx Report

Node   : 20.9.0
OS     : win32-x64
npm    : 9.1.2

nx (global)        : 18.0.8
nx                 : 18.0.8
@nx/js             : 18.0.8
@nx/jest           : 18.0.8
@nx/linter         : 18.0.8
@nx/eslint         : 18.0.8
@nx/workspace      : 18.0.8
@nx/angular        : 18.0.8
@nx/cypress        : 18.0.8
@nx/devkit         : 18.0.8
@nx/eslint-plugin  : 18.0.8
@nx/nest           : 18.0.8
@nx/node           : 18.0.8
@nrwl/tao          : 18.0.8
@nx/web            : 18.0.8
@nx/webpack        : 18.0.8
typescript         : 5.3.3
---------------------------------------
Community plugins:
@auth0/auth0-angular : 2.2.3
@ngrx/component      : 17.1.1

Failure Logs

No response

Package Manager Version

No response

Operating System

• [ ] macOS
• [ ] Linux
• [X] Windows
• [ ] Other (Please specify)

Additional Information

Using "checkObsoleteDependencies": false I can disable the removal of my existing dependencies for now.

[L-NiNo]

Helveg i had this issue during upgrading and discovered I that the package-lock is required to pull 3rd party imports correctly. I opened a issue to add it to the documentation https://github.com/nrwl/nx/issues/22442.

It might not be applicable to your use case, but worth mentioning.

[FrozenPandaz]

So the lint rule is definitely able to find these dependencies here in the Nx repo. We'll need more information in order to help you resolve your issue.

What version did you migrate from? Does nx reset fix the issue? Is it possible to provide a minimal reproduction to make reproducing the issue easier?

[Helveg]

So I think I had the same issue as @L-NiNo. Since removing package-lock.json is a pretty common operation during a major version migration of a peer dependency (e.g. the main frameworks used in the project), I think @nx/dependency-checks should warn and noop, or error out when there's no package-lock.json to derive dependencies from.

With package-lock.json present in the root directory @nx/dependency-checks seems to operate normally again.

[github-actions[bot]]

This issue has been automatically marked as stale because it hasn't had any recent activity. It will be closed in 14 days if no further activity occurs. If we missed this issue please reply to keep it active. Thanks for being a part of the Nx community! 🙏

[binaryartifex]

can confirm. ive wasted an entire afternoon on this damn thing. this linting plugin has just suddenly decided all the deps in the plugins package.json arn't being used. they certainly are. ive redownloaded deps, reset nx a million which ways.

1. create a plugin using the nx generator using the swc compiler at plugins/foobar
2. in the package.json there should be an swc helpers dependency
3. run linting. watch linting fail.
4. run build. watch build output a warning also saying Your library compilation option specifies that the compiler external helper (@swc/helpers) is needed but it is not installed. it also proceeds to tell me all the packages that are being imported into it from the workspace are outside the configured rootDir of plugin/[myplugin]. ive tried setting the rootDir all over the place and its just ignored.

[Helveg]

@binaryartifex what about your package-lock.json? Also, even stupider, have you tried fully restarting your computer? I basically just disabled the plugin, came back to it a few days later, and it suddenly worked again.

I used these options to disable the failing linting rules:

      "checkMissingDependencies": true, // toggle to disable
      "checkObsoleteDependencies": true, // toggle to disable
      "checkVersionMismatches": true // toggle to disable

set them to false to disable

[binaryartifex]

that takes care of the linting but honestly kinda defeats the purpose of a build package linter in the first place. the build step however has suddenly decided not to work at all. workspace plugins never use to have their own package.json, which was great for simple executors, etc that you wanted within the scope of your own integrated monorepo. reference my concern above with the build executor not finding swc helpers at all, ffs, they are installed, they are in the package.json of the plugin, its never been an issue before...wtf? utilities in the libs external to the plugin all of a sudden cannot be imported. there's now what must be a static rootDir set somewhere that refuses to be overridden so i can't tell this bloody thing it can in fact, look outside the plugin for its imports....what was meant to be literally a swap out for a business logo has got me grinding into the night to fix yet another random nx issue....sigh

[L-NiNo]

Helveg i had this issue during upgrading and discovered I that the package-lock is required to pull 3rd party imports correctly. I opened a issue to add it to the documentation https://github.com/nrwl/nx/issues/22442.

It might not be applicable to your use case, but worth mentioning.

Also worth noting, package-lock cannot be gitignored

[DenizUgur]

I'm using pnpm and cannot actually pinpoint when this rule stopped working but even though my library is buildable the rule does not detect dependencies used in my project. How does this rule even work in the first place? Maybe I'm missing something that broke this rule.

[github-actions[bot]]

This issue has been automatically marked as stale because no reproduction was provided within 7 days. Please help us help you. Providing a repository exhibiting the issue helps us diagnose and fix the issue. Any time that we spend reproducing this issue is time taken away from addressing this issue and other issues. This issue will be closed in 21 days if a reproduction is not provided. If a reproduction has been provided, please reply to keep it active. Thanks for being a part of the Nx community! 🙏

[marcolongol]

Can confirm this is happening with me as well and it started after i added @nxlv/python to my monorepo and creating a new python project

C:\Users\lucas\OneDrive\Desktop\Sandbox\marcolongoldt\marcolongo.cloud\libs\common-ui\package.json
   5:5  warning  The "@angular/common" package is not used by "common-ui" project         @nx/dependency-checks
   6:5  warning  The "@angular/core" package is not used by "common-ui" project           @nx/dependency-checks
   7:5  warning  The "@angular/router" package is not used by "common-ui" project         @nx/dependency-checks
   8:5  warning  The "@marcolongo.cloud/core" package is not used by "common-ui" project  @nx/dependency-checks
  10:5  warning  The "@pdftron/webviewer" package is not used by "common-ui" project      @nx/dependency-checks

NX Report:

Node   : 20.13.1
OS     : win32-x64
npm    : 10.5.2

nx                 : 19.0.4
@nx/js             : 19.0.4
@nx/jest           : 19.0.4
@nx/linter         : 19.0.4
@nx/eslint         : 19.0.4
@nx/workspace      : 19.0.4
@nx/angular        : 19.0.4
@nx/cypress        : 19.0.4
@nx/devkit         : 18.3.4
@nx/eslint-plugin  : 19.0.4
@nx/storybook      : 19.0.4
@nrwl/tao          : 19.0.4
@nx/web            : 19.0.4
@nx/webpack        : 19.0.4
typescript         : 5.4.5
---------------------------------------
Registered Plugins:
@nxlv/python
@nx/cypress/plugin
@nx/eslint/plugin
---------------------------------------
Community plugins:
@fortawesome/angular-fontawesome : 0.14.1
@jscutlery/semver                : 5.2.2
@nx-tools/nx-container           : 6.0.0
@nxlv/python                     : 18.1.0
@storybook/angular               : 8.1.1
nx-stylelint                     : 17.1.4
---------------------------------------
The following packages should match the installed version of nx
- @nx/[email protected]
- @nrwl/[email protected]

To fix this, run `nx migrate [email protected]`

For now, i have changed the rule to warn untill it's fixed:

    {
      "files": ["*.json"],
      "parser": "jsonc-eslint-parser",
      "rules": {
        "@nx/dependency-checks": "warn"
      }
    }

[github-actions[bot]]

This issue has been automatically marked as stale because no reproduction was provided within 7 days. Please help us help you. Providing a repository exhibiting the issue helps us diagnose and fix the issue. Any time that we spend reproducing this issue is time taken away from addressing this issue and other issues. This issue will be closed in 21 days if a reproduction is not provided. If a reproduction has been provided, please reply to keep it active. Thanks for being a part of the Nx community! 🙏

[tinesoft]

I have the same issue here

I confirm it has something to do with package manager used (I'm using pnpm), When removing the node_modules and pnpm-lock.yaml, then reinstalling the deps with pure npm, the lint results are slightly better:

• used external dependencies are detected properly
• BUT
  • internal wildcard dependencies (example: "my-package": "*") are removed after linting with --fix ...

See my repo at https://github.com/tinesoft/nxrocks/

[beeman]

I also have issues with the @nx/dependency-checks plugin. It tries to remove dependencies that I depend on.

Here is one of the repos where this happens but I have it in various.

[JamesHenry]

@beeman are there steps required to reproduce this?

When I do a fresh clone of your repo, I get this lint feedback, which seems to be accurate:

7:5 error The version specifier does not contain the installed version of "@pubkey-program-library/anchor" package: 1.5.0 @nx/dependency-checks

[beeman]

@beeman are there steps required to reproduce this?

When I do a fresh clone of your repo, I get this lint feedback, which seems to be accurate:

Thanks for testing this @JamesHenry! Can you try switching to the beeman/identity-providers branch and see what that does?

[JamesHenry]

@beeman you are using pnpm lockfile v9 which is not supported by the Nx version you are using. We merged support for it already and it will be available in the upcoming Nx 19.2.

When I check out that branch and run pnpm install, my installed (supported) v8 version of pnpm rewrites the lock file automatically because it doesn't recognize it.

Linting passes in this scenario:

So in your case it is likely down to the unsupported lock file.

The latest prerelease for 19.2 is currently being released, so I will try that on your branch once it is ready without any modifications to your lock file to compare.

[JamesHenry]

@beeman Confirmed, yours is down to the unsupported lock file only. 19.2 prereleases, such as 19.2.0-beta.2, resolve the issue on that branch.

[JamesHenry]

Please can all others on this thread try updating to 19.2.0-beta.2 and seeing if it resolves their issues? We believe it should as it more accurately matches external nodes (npm packages) to projects

[beeman]

@beeman Confirmed, yours is down to the unsupported lock file only. 19.2 prereleases, such as 19.2.0-beta.2, resolve the issue on that branch.

Thanks a lot for checking this out and suggesting the solution! I'll test the new version and confirm back here!

[beeman]

@beeman Confirmed, yours is down to the unsupported lock file only. 19.2 prereleases, such as 19.2.0-beta.2, resolve the issue on that branch.

Just updated to the latest beta and this fixes this issue in my repo! Thanks! 🙏

[github-actions[bot]]

This issue has been automatically marked as stale because no reproduction was provided within 7 days. Please help us help you. Providing a repository exhibiting the issue helps us diagnose and fix the issue. Any time that we spend reproducing this issue is time taken away from addressing this issue and other issues. This issue will be closed in 21 days if a reproduction is not provided. If a reproduction has been provided, please reply to keep it active. Thanks for being a part of the Nx community! 🙏

[MPFGlaser]

I still have issues with this, even on v19. Might have something to do with me using publishable libraries only in my project.

[Markus-Ende]

Had the same issue when upgrading to 19.3.2, using npm. Was fixed by re-generating package-lock.

[github-actions[bot]]

This issue has been automatically marked as stale because no reproduction was provided within 7 days. Please help us help you. Providing a repository exhibiting the issue helps us diagnose and fix the issue. Any time that we spend reproducing this issue is time taken away from addressing this issue and other issues. This issue will be closed in 21 days if a reproduction is not provided. If a reproduction has been provided, please reply to keep it active. Thanks for being a part of the Nx community! 🙏

[jkossis]

Ran into this just now, on 19.5.6. Anyone else seeing this?

[Hotell]

@JamesHenry tried to enable this rule today and following getting weird errors:

I also noticed that projectFileMap is generated in weird way - the deps is completely missing

 {
      file: 'packages/react-components/react-text/library/src/components/presets/Body1Stronger/index.ts',
      hash: '2880256041137615974'
    },
    {
      file: 'packages/react-components/react-text/library/src/components/presets/Body1Stronger/useBody1StrongerStyles.styles.ts',
      hash: '17438350325437671483'
    },
    {
      file: 'packages/react-components/react-text/library/src/components/presets/Body2/Body2.tsx',
      hash: '16105280774354904702'
    },
    {
      file: 'packages/react-components/react-text/library/src/components/presets/Body2/index.ts',
      hash: '7846029568414333221'
    },

which will result in empty npmDependencies collection within the rule as this will never be executed

NOTE: we don't use source analyzer because legacy reasons

  "pluginsConfig": {
    "@nx/js": {
      "analyzeSourceFiles": false
    }
  },

quick repro:

• clone https://github.com/microsoft/fluentui
• update packages/react-components/react-text/library/.eslintrc.json to

{
  "root": true,
  "parser": "@typescript-eslint/parser",
  "plugins": ["@nx","@typescript-eslint"],
  "env": {
    "browser": true
  },
  "rules": {
    "import/no-extraneous-dependencies": "off",
    "react-compiler/react-compiler": "off"
  },
  "overrides": [
    {
      "files": ["*.json"],
      "parser": "jsonc-eslint-parser",
      "rules": {
        "@nx/dependency-checks": "error"
      }
    }
  ]
}

• update scripts/tasks/src/eslint.ts#7 to const files = [path.join(process.cwd(), 'package.json'), path.join(process.cwd(), eslintConstants.directory)];
• run yarn workspace @fluentui/react-text lint

[github-actions[bot]]

This issue has been closed for more than 30 days. If this issue is still occuring, please open a new issue with more recent context.