-
Notifications
You must be signed in to change notification settings - Fork 162
👷 fix MODULE_TYPELESS_PACKAGE_JSON warning #3906
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
👷 fix MODULE_TYPELESS_PACKAGE_JSON warning #3906
Conversation
Bundles Sizes Evolution
🚀 CPU PerformancePending... 🧠 Memory Performance
|
|
✅ Tests 🎉 All green!❄️ No new flaky tests detected 🎯 Code Coverage 🔗 Commit SHA: e44f9de | Docs | Datadog PR Page | Was this helpful? Give us feedback! |
40a2024 to
bf31991
Compare
bf31991 to
656b69b
Compare
…y getRunId function to return 'n/a' if no CI_JOB_ID or USER is set
… imports in karma.bs.conf.js
…ve unused lint function from cli script
…ProdDepsImports - Implemented disallowProtectedDirectoryImport to prevent importing from directories containing an "index" file. - Created enforceProdDepsImports to ensure only production dependencies are imported in production files. - Updated index.js to include the new rules.
…les in rules and scripts directories
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
💡 Codex Review
Here are some automated review suggestions for this pull request.
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| import resolvePackage from 'eslint-module-utils/resolve.js' | ||
| import moduleVisitorPackage from 'eslint-module-utils/moduleVisitor.js' | ||
| import importTypePackage from 'eslint-plugin-import/lib/core/importType.js' | ||
|
|
||
| const moduleVisitor = moduleVisitorPackage.default | ||
| const importType = importTypePackage.default | ||
| const resolve = resolvePackage.default |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Preserve default exports when importing ESLint helper utilities
The refactor to ESM imports replaces require('…').default with import … from '…'; const fn = imported.default. In ESM, the value bound by import foo from 'pkg' is already the default export; accessing .default again yields undefined when the module exports a function. As a result moduleVisitor, importType, and resolve are undefined and the rule throws as soon as it runs. Import the default directly (import moduleVisitor from 'eslint-module-utils/moduleVisitor.js') or fall back to the object when default is missing.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
these modules are weird, we need the default key from the default export 🙄
[Module: null prototype] {
CASE_SENSITIVE_FS: false,
__esModule: true,
default: {
__esModule: true,
CASE_SENSITIVE_FS: false,
fileExistsWithCaseSync: [Function: fileExistsWithCaseSync],
relative: [Function: relative],
default: [Function: resolve] { relative: [Function: relative] }
},
fileExistsWithCaseSync: [Function: fileExistsWithCaseSync],
'module.exports': {
__esModule: true,
CASE_SENSITIVE_FS: false,
fileExistsWithCaseSync: [Function: fileExistsWithCaseSync],
relative: [Function: relative],
default: [Function: resolve] { relative: [Function: relative] }
},
relative: [Function: relative]
}
| import moduleVisitorPackage from 'eslint-module-utils/moduleVisitor.js' | ||
| import importTypePackage from 'eslint-plugin-import/lib/core/importType.js' | ||
| import pkgUpPackage from 'eslint-module-utils/pkgUp.js' | ||
|
|
||
| const moduleVisitor = moduleVisitorPackage.default | ||
| const pkgUp = pkgUpPackage.default | ||
| const importType = importTypePackage.default |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Default import handling breaks ESLint rule initialisation
Similar to the protected-directory rule, these helpers are now imported via import … from … and immediately dereferenced with .default. When eslint-module-utils/eslint-plugin-import are ESM bundles, the default import already returns the function; .default is undefined and the rule fails at runtime (TypeError: pkgUp is not a function). Linting will abort before running. Use the default import directly or guard against missing default.
Useful? React with 👍 / 👎.
| } | ||
|
|
||
| const packagesRoot = path.resolve(__dirname, '..', 'packages') | ||
| const packagesRoot = path.resolve(import.meta.dirname, '..', 'packages') |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
import.meta.dirname usage requires a newer Node than project declares
The rule now resolves packagesRoot via path.resolve(import.meta.dirname, …). import.meta.dirname is only available starting with Node 22; with the current project setup (no engine bump and the repository historically using Node 18/20), this property is undefined, causing the rule to crash when ESLint is loaded. To remain compatible with supported Node versions, compute the directory using fileURLToPath(new URL('.', import.meta.url)) or similar.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we use node 24
| import resolvePackage from 'eslint-module-utils/resolve.js' | ||
| import moduleVisitorPackage from 'eslint-module-utils/moduleVisitor.js' | ||
| import importTypePackage from 'eslint-plugin-import/lib/core/importType.js' | ||
|
|
||
| const moduleVisitor = moduleVisitorPackage.default | ||
| const importType = importTypePackage.default | ||
| const resolve = resolvePackage.default |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
❓ question: Not from this PR, but are we using internals here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it seems so
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's not internal, it's actual public exports: https://github.com/import-js/eslint-plugin-import/blob/01c9eb04331d2efa8d63f2d7f4bfec3bc44c94f3/utils/package.json#L9-L38
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well, maybe eslint-plugin-import/lib/core/importType.js is internal :D
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
❓ question: I remember seeing an explanation for this in Slack. How can we keep the explanation in the codebase so we don't forget why we need this as private?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
test/e2e is not type: module because in some scenario we import some build cjs files (example)
Indeed this is a bit of a hack, but this PR already improve things and we can always review the e2e test to not rely on these cjs file later.
I can't add comment to a package.json file, I guess blaming this file will make this PR (and this comment) visible.
| @@ -1,6 +1,6 @@ | |||
| const path = require('path') | |||
| import path from 'path' | |||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
| import path from 'path' | |
| import path from 'node:path' |
| @@ -1,6 +1,6 @@ | |||
| const path = require('path') | |||
| import path from 'path' | |||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
| import path from 'path' | |
| import path from 'node:path' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would that work for you if I fix these in a separate PR using import/enforce-node-protocol-usage? there is a lot more than these few instances.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
wip: #3943
| @@ -1,12 +1,12 @@ | |||
| const os = require('os') | |||
| import os from 'os' | |||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
| import os from 'os' | |
| import os from 'node:os' |
Motivation
Remove the annoying
MODULE_TYPELESS_PACKAGE_JSONwarning when running most of the node command.Changes
Test instructions
Checklist