Conversation
There are some packages which import files from other packages using relative imports. This won't work in production code, and TypeScript will type the imports as `any`, which will damage type-safety upstream. This commit adds an ESLint rule which checks to ensure that cross-package relative imports are not being used and suggests that the engineer directly import the package instead. There are some existing lint violations, so this commit also instructs ESLint to suppress them.
| "count": 6 | ||
| } | ||
| }, | ||
| "packages/assets-controller/src/__fixtures__/MockAssetControllerMessenger.ts": { |
There was a problem hiding this comment.
I don't think these files should be in src/, they should probably be in tests/ instead, but we can address that in another PR.
eslint.config.mjs
Outdated
| { | ||
| // Prohibit relative imports that cross package boundaries in non-test files. | ||
| // This is like the `no-relative-packages` rule in the `import-x` plugin, | ||
| // but does not suggest that engineers use subpath imports that may or may |
There was a problem hiding this comment.
The error from the import-x plugin comes from here. For the following code:
import type { MultichainAccountServiceWalletStatusChangeEvent } from '../../multichain-account-service/src/types';the error would be:
Relative import from another package is not allowed. Use `@metamask/multichain-account-service/src/types` instead of `../../multichain-account-service/src/types`
However, @metamask/multichain-account-service/src/types is not a valid export path, so this won't be useful for engineers.
There was a problem hiding this comment.
That error message isn't bad IMO. It would still lead contributors in the right direction.
There was a problem hiding this comment.
True. I guess I was a bit worried as well because if you ran yarn lint:fix and you didn't know better, no-relative-packages would apply an autofix that caused a build failure. Should something that passes lint cause a different error somewhere else? That feels strange to me.
There was a problem hiding this comment.
Oh, but I guess the bad path would get flagged in your IDE by a different lint rule and/or tsserver. Hmm... Maybe it would be okay to just use no-relative-packages after all.
2 participants
Explanation
There are some packages which import files from other packages using relative imports. This won't work in production code, and TypeScript will type the imports as
any, which will damage type-safety upstream.This commit adds an ESLint rule which checks to ensure that cross-package relative imports are not being used and suggests that the engineer directly import the package instead. There are some existing lint violations of the new rule in this repo, so this commit also instructs ESLint to suppress them (we will address them in other PRs).
References
(These problems were discovered while working on the UI messenger integration prototype)
Checklist
Note
Medium Risk
Repo-wide ESLint rule change that can introduce new lint failures in production
packages/*/src/**/*.tsas code is touched or when suppressions drift. Functionality/runtime behavior is unchanged, but developer workflows and CI linting may be impacted.Overview
Adds an ESLint check to forbid cross-package relative imports in non-test TypeScript sources under
packages/*/src/**/*.tsviaimport-x/no-relative-packages.Updates
eslint-suppressions.jsonto temporarily suppress existing violations in a handful of files so the new rule can be enabled without immediately failing lint.Written by Cursor Bugbot for commit c1a516e. This will update automatically on new commits. Configure here.