Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

enforce-module-boundaries - banTransitiveDependencies only looks at workspace package.json #15129

Closed
ilijapuaca opened this issue Feb 20, 2023 · 2 comments · Fixed by #15169
Closed
Assignees
Labels
outdated scope: linter Issues related to Eslint support in Nx type: bug

Comments

@ilijapuaca
Copy link

ilijapuaca commented Feb 20, 2023

Current Behavior

When banTransitiveDependencies is enabled, eslint plugin will report Transitive dependencies are not allowed. Only packages defined in the "package.json" can be importedeslint[@nrwl/nx/enforce-module-boundaries], even though the dependency is present in the package.json of that module.

This seems to happen because isDirectDependency only takes the workspace package.json into account, making the rule not very usable for projects with multiple package.json files.

While I understand that a single package.json is the recommended way of dealing with dependencies, there seemed to be some momentum towards supporting use cases outside of it in this thread. It seems relatively(?) straight-forward to add support for this linting use case by simply tweaking the function noted above which would take more than a single package.json into account.

Expected Behavior

The rule does not report an error when the dependency is present in app package.json

GitHub Repo

No response

Steps to Reproduce

  1. Enable @nrwl/nx/enforce-module-boundaries with banTransitiveDependencies set to true
  2. Add an external dependency to app-level package.json
  3. Import that dependency, an error shows up

Nx Report

>  NX   Report complete - copy this into the issue template

   Node : 14.21.1
   OS   : darwin x64
   yarn : 3.2.4

   nx : 15.0.4
   @nrwl/angular : Not Found
   @nrwl/cypress : Not Found
   @nrwl/detox : Not Found
   @nrwl/devkit : 15.0.4
   @nrwl/esbuild : Not Found
   @nrwl/eslint-plugin-nx : 15.0.4
   @nrwl/expo : Not Found
   @nrwl/express : Not Found
   @nrwl/jest : 15.0.4
   @nrwl/js : 15.0.4
   @nrwl/linter : 15.0.4
   @nrwl/nest : Not Found
   @nrwl/next : Not Found
   @nrwl/node : Not Found
   @nrwl/nx-cloud : Not Found
   @nrwl/nx-plugin : Not Found
   @nrwl/react : Not Found
   @nrwl/react-native : Not Found
   @nrwl/rollup : Not Found
   @nrwl/schematics : Not Found
   @nrwl/storybook : Not Found
   @nrwl/web : Not Found
   @nrwl/webpack : Not Found
   @nrwl/workspace : 15.0.4
   typescript : 4.8.4
   ---------------------------------------
   Local workspace plugins:
   ---------------------------------------
   Community plugins:

Failure Logs

No response

Additional Information

While I understand that per-app package.json approach seems like a somewhat controversial topic, there seems to be a large enough user base that would benefit from a small tweak to make this specific lint rule usable

@ilijapuaca ilijapuaca changed the title enforce-module-boundaries - banTransitiveDependencies only looks at root package.json enforce-module-boundaries - banTransitiveDependencies only looks at workspace package.json Feb 20, 2023
@AgentEnder AgentEnder added the scope: linter Issues related to Eslint support in Nx label Feb 21, 2023
@meeroslav
Copy link
Contributor

Thank you, @ilijapuaca, for reporting this issue.

It is an oversight on our side, which we will fix as soon as possible.

@github-actions
Copy link

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.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Mar 24, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
outdated scope: linter Issues related to Eslint support in Nx type: bug
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants