You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The ESLint rule @nx/dependency-checks will show an error if @mypkg/foo isn't listed in either dependencies or peerDependencies of package.json. That's fine, that's the purpose of the rule.
However, in a type-only import situation such as this:
importtype{Foo}from '@mypkg/foo`
Today, this still trips up the rule… even if the package is listed in the devDependencies section of package.json.
Expected Behavior
Type-only imports such as listed above are only needed at compile time. Therefore, having these packages referenced in the devDependencies section package.json should suffice to satisfy the ESLint rule @nx/dependency-checks
GitHub Repo
No response
Steps to Reproduce
Add some package for which you need type info at compile time in the devDependencies section of package.json
Type-only Import that in a file (e.g. import type { Foo } from '@mypkg/foo';)
Run the linter on that package (npx nx lint {project-name})
Notice the linter error:
error The "{project-name}" project uses the following packages, but they are missing from "dependencies":
- @mypkg/foo @nx/dependency-checks
✖ 1 problem (1 error, 0 warnings)
1 error and 0 warnings potentially fixable with the `--fix` option.
Nx Report
NX Report complete - copy this into the issue template
Node : 16.20.2
OS : darwin-arm64
pnpm : 8.15.1
nx (global) : 18.0.3
nx : 18.2.3
@nx/js : 18.2.3
@nx/jest : 18.2.3
@nx/eslint : 18.2.3
@nx/workspace : 18.2.3
@nx/devkit : 18.2.3
@nx/eslint-plugin : 18.2.3
@nx/playwright : 18.2.3
@nx/plugin : 18.2.3
@nx/react : 18.2.3
@nrwl/tao : 18.0.3
@nx/vite : 18.2.3
@nx/web : 18.2.3
typescript : 5.4.4
---------------------------------------
The following packages should match the installed version of nx
- @nrwl/tao@18.0.3
To fix this, run `nx migrate nx@18.2.3`
Failure Logs
No response
Package Manager Version
pnpm 8.15.1
Operating System
macOS
Linux
Windows
Other (Please specify)
Additional Information
No response
The text was updated successfully, but these errors were encountered:
This is not necessarily true. If you have a code that looks like this:
importtype{Foo}from '@mypkg/foo`
export type Baz = {
foo: Foo;
}
Then your exported d.ts file will still have a reference to @mypkg/foo.
The rule at this level doesn't know the intention of how that Foo type will be used so it will consider that it might end up being exported. As a developer you know which dependencies will never end up in the resulting artifact so you can manually exclude them via ignoredDependencies parameter.
The problem with suppressing it wholesale for a package is that it might fly under the radar if you're using the package as a proper runtime dep somewhere else in the future.
Is there a way to tell the linter in the import statements to ignore that import as a more finer-grained toggle? Similar to how you don't have to suppress all use of say any and you can selectively do it for some lines only.
Current Behavior
If you import a library like so:
The ESLint rule
@nx/dependency-checks
will show an error if@mypkg/foo
isn't listed in eitherdependencies
orpeerDependencies
ofpackage.json
. That's fine, that's the purpose of the rule.However, in a type-only import situation such as this:
Today, this still trips up the rule… even if the package is listed in the
devDependencies
section ofpackage.json
.Expected Behavior
Type-only imports such as listed above are only needed at compile time. Therefore, having these packages referenced in the
devDependencies
sectionpackage.json
should suffice to satisfy the ESLint rule@nx/dependency-checks
GitHub Repo
No response
Steps to Reproduce
devDependencies
section ofpackage.json
import type { Foo } from '@mypkg/foo';
)npx nx lint {project-name}
)Nx Report
Failure Logs
No response
Package Manager Version
pnpm 8.15.1
Operating System
Additional Information
No response
The text was updated successfully, but these errors were encountered: