@nx/dependency-checks should not trigger for type-only imports

[osuritz-grammarly]

Current Behavior

If you import a library like so:

import { Foo } from '@mypkg/foo`

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:

import type { 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

1. Add some package for which you need type info at compile time in the devDependencies section of package.json
2. Type-only Import that in a file (e.g. import type { Foo } from '@mypkg/foo';)
3. Run the linter on that package (npx nx lint {project-name})
4. 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/[email protected]

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

Failure Logs

No response

Package Manager Version

pnpm 8.15.1

Operating System

• macOS
• Linux
• Windows
• Other (Please specify)

Additional Information

No response

[meeroslav]

Hi,

This is not necessarily true. If you have a code that looks like this:

import type { 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.

[osuritz-grammarly]

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.