feat: migrate to ESM primary #271
Conversation
🦋 Changeset detectedLatest commit: f4999b6 The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
WalkthroughThis pull request introduces a comprehensive refactoring across configuration, source, rule, utility, and test files. The changes shift the codebase from CommonJS to ECMAScript modules by updating export syntax, adding explicit “.js” extensions to import paths, and converting many type aliases into interfaces. Additionally, new configuration files (such as for ESLint documentation and TypeScript projects) are added while obsolete ones are removed. The updates also include adjustments in CI workflows, package.json exports, and test setups to improve module resolution and overall type safety. Changes
Poem
🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
|
This pull request is automatically built and testable in CodeSandbox. To see build info of the built libraries, click here or the icon next to each commit SHA. |
|
Report too large to display inline |
commit: |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 4
🧹 Nitpick comments (4)
test/utils/export-map.spec.ts (2)
15-114: Extracted reusable test function for better modularityThe
jsdocTestsfunction extracts common test patterns for deprecated imports into a reusable function, improving code organization and reducing duplication when testing with different parsers and line endings.Consider breaking this large function into smaller helper functions for specific test scenarios (e.g., one for named imports, one for default imports) to further improve readability and maintainability.
445-487: Updated tsconfig caching test for ESM compatibilityThe test for tsconfig caching has been updated to work with the new mocking approach, properly validating that
getTsconfigis called the expected number of times.Consider adding a brief comment explaining the expected caching behavior to help future maintainers understand this test more easily:
+// Ensure getTsconfig is only called when the tsconfigRootDir changes, validating the caching mechanism it('should cache tsconfig until tsconfigRootDir parser option changes', async () => {test/rules/no-unresolved.spec.ts (1)
1-1: Using Node.js built-in createRequireThis file uses Node.js built-in
createRequireinstead of thecjsRequirefrom@pkgr/coreused in other test files. While both approaches work, this creates an inconsistency in how CommonJS compatibility is achieved across the test files.Consider standardizing on either
cjsRequirefrom@pkgr/coreor Node's built-increateRequireacross all test files for consistency.src/utils/export-map.ts (1)
889-890: Consider rephrasing the comment to be more professional.While the renaming of
forEachto$forEachmakes sense for compatibility with future changes, the comment contains "WTF?!" which is unprofessional. Consider rephrasing to something more descriptive like "Note:forEachwill be transformed into.entries()in future versions."- // FIXME: `forEach` will be transformed into `.entries()`, WTF?! + // FIXME: `forEach` will be transformed into `.entries()` in future versions
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (2)
test/__snapshots__/node-resolver.spec.ts.snapis excluded by!**/*.snapyarn.lockis excluded by!**/yarn.lock,!**/*.lock
📒 Files selected for processing (161)
.env.yarn(0 hunks).eslint-doc-generatorrc.js(1 hunks).eslint-doc-generatorrc.mjs(0 hunks).eslintignore(0 hunks).eslintrc.cjs(5 hunks).github/workflows/ci.yml(2 hunks).github/workflows/codeql.yml(1 hunks)eslint.config.js(1 hunks)index.d.cts(1 hunks)jest.config.ts(2 hunks)package.json(7 hunks)patches/@swc-node+jest+1.8.13.patch(1 hunks)src/config/electron.ts(1 hunks)src/config/errors.ts(1 hunks)src/config/flat/electron.ts(1 hunks)src/config/flat/errors.ts(1 hunks)src/config/flat/react-native.ts(1 hunks)src/config/flat/react.ts(1 hunks)src/config/flat/recommended.ts(1 hunks)src/config/flat/stage-0.ts(1 hunks)src/config/flat/typescript.ts(1 hunks)src/config/flat/warnings.ts(1 hunks)src/config/react-native.ts(1 hunks)src/config/react.ts(2 hunks)src/config/recommended.ts(1 hunks)src/config/stage-0.ts(1 hunks)src/config/typescript.ts(2 hunks)src/config/warnings.ts(1 hunks)src/index.ts(3 hunks)src/meta.ts(1 hunks)src/node-resolver.ts(2 hunks)src/rules/consistent-type-specifier-style.ts(2 hunks)src/rules/default.ts(1 hunks)src/rules/dynamic-import-chunkname.ts(2 hunks)src/rules/export.ts(3 hunks)src/rules/exports-last.ts(2 hunks)src/rules/extensions.ts(3 hunks)src/rules/first.ts(2 hunks)src/rules/group-exports.ts(2 hunks)src/rules/imports-first.ts(1 hunks)src/rules/max-dependencies.ts(1 hunks)src/rules/named.ts(1 hunks)src/rules/namespace.ts(2 hunks)src/rules/newline-after-import.ts(2 hunks)src/rules/no-absolute-path.ts(1 hunks)src/rules/no-amd.ts(1 hunks)src/rules/no-anonymous-default-export.ts(3 hunks)src/rules/no-commonjs.ts(2 hunks)src/rules/no-cycle.ts(1 hunks)src/rules/no-default-export.ts(1 hunks)src/rules/no-deprecated.ts(2 hunks)src/rules/no-duplicates.ts(2 hunks)src/rules/no-dynamic-require.ts(2 hunks)src/rules/no-empty-named-blocks.ts(2 hunks)src/rules/no-extraneous-dependencies.ts(5 hunks)src/rules/no-import-module-exports.ts(2 hunks)src/rules/no-internal-modules.ts(2 hunks)src/rules/no-mutable-exports.ts(1 hunks)src/rules/no-named-as-default-member.ts(1 hunks)src/rules/no-named-as-default.ts(1 hunks)src/rules/no-named-default.ts(1 hunks)src/rules/no-named-export.ts(1 hunks)src/rules/no-namespace.ts(1 hunks)src/rules/no-nodejs-modules.ts(1 hunks)src/rules/no-relative-packages.ts(2 hunks)src/rules/no-relative-parent-imports.ts(1 hunks)src/rules/no-rename-default.ts(1 hunks)src/rules/no-restricted-paths.ts(3 hunks)src/rules/no-self-import.ts(2 hunks)src/rules/no-unassigned-import.ts(2 hunks)src/rules/no-unresolved.ts(2 hunks)src/rules/no-unused-modules.ts(4 hunks)src/rules/no-useless-path-segments.ts(2 hunks)src/rules/no-webpack-loader-syntax.ts(1 hunks)src/rules/order.ts(3 hunks)src/rules/prefer-default-export.ts(1 hunks)src/rules/unambiguous.ts(1 hunks)src/types.ts(12 hunks)src/utils/create-rule.ts(1 hunks)src/utils/declared-scope.ts(1 hunks)src/utils/docs-url.ts(1 hunks)src/utils/export-map.ts(5 hunks)src/utils/ignore.ts(1 hunks)src/utils/import-declaration.ts(1 hunks)src/utils/import-type.ts(1 hunks)src/utils/index.ts(1 hunks)src/utils/legacy-resolver-settings.ts(5 hunks)src/utils/module-cache.ts(1 hunks)src/utils/module-require.ts(2 hunks)src/utils/module-visitor.ts(1 hunks)src/utils/package-path.ts(1 hunks)src/utils/parse.ts(1 hunks)src/utils/pkg-dir.ts(1 hunks)src/utils/read-pkg-up.ts(1 hunks)src/utils/resolve.ts(2 hunks)src/utils/source-type.ts(1 hunks)src/utils/static-require.ts(1 hunks)test/cli.spec.ts(4 hunks)test/fixtures/tsconfig.json(1 hunks)test/index.js(1 hunks)test/jest.serializer.cjs(1 hunks)test/jest.serializer.ts(0 hunks)test/node-resolver.spec.ts(3 hunks)test/package.spec.ts(3 hunks)test/rules/consistent-type-specifier-style.spec.ts(3 hunks)test/rules/default.spec.ts(7 hunks)test/rules/dynamic-import-chunkname.spec.ts(2 hunks)test/rules/export.spec.ts(4 hunks)test/rules/exports-last.spec.ts(1 hunks)test/rules/extensions.spec.ts(1 hunks)test/rules/first.spec.ts(2 hunks)test/rules/group-exports.spec.ts(1 hunks)test/rules/max-dependencies.spec.ts(1 hunks)test/rules/named.spec.ts(5 hunks)test/rules/namespace.spec.ts(2 hunks)test/rules/newline-after-import.spec.ts(1 hunks)test/rules/no-absolute-path.spec.ts(1 hunks)test/rules/no-anonymous-default-export.spec.ts(2 hunks)test/rules/no-cycle.spec.ts(1 hunks)test/rules/no-default-export.spec.ts(1 hunks)test/rules/no-deprecated.spec.ts(1 hunks)test/rules/no-duplicates.spec.ts(2 hunks)test/rules/no-dynamic-require.spec.ts(3 hunks)test/rules/no-empty-named-blocks.spec.ts(1 hunks)test/rules/no-extraneous-dependencies.spec.ts(5 hunks)test/rules/no-import-module-exports.spec.ts(1 hunks)test/rules/no-internal-modules.spec.ts(1 hunks)test/rules/no-mutable-exports.spec.ts(1 hunks)test/rules/no-named-as-default-member.spec.ts(2 hunks)test/rules/no-named-as-default.spec.ts(2 hunks)test/rules/no-named-default.spec.ts(1 hunks)test/rules/no-named-export.spec.ts(1 hunks)test/rules/no-namespace.spec.ts(1 hunks)test/rules/no-nodejs-modules.spec.ts(1 hunks)test/rules/no-relative-packages.spec.ts(1 hunks)test/rules/no-relative-parent-imports.spec.ts(1 hunks)test/rules/no-rename-default.spec.ts(1 hunks)test/rules/no-restricted-paths.spec.ts(1 hunks)test/rules/no-self-import.spec.ts(1 hunks)test/rules/no-unassigned-import.spec.ts(1 hunks)test/rules/no-unresolved.spec.ts(2 hunks)test/rules/no-unused-modules.spec.ts(2 hunks)test/rules/no-useless-path-segments.spec.ts(1 hunks)test/rules/no-webpack-loader-syntax.spec.ts(1 hunks)test/rules/order.spec.ts(2 hunks)test/rules/prefer-default-export.spec.ts(2 hunks)test/rules/unambiguous.spec.ts(2 hunks)test/tsconfig.json(1 hunks)test/utils.ts(3 hunks)test/utils/eslint-parser.cts(1 hunks)test/utils/eslint-parser.ts(0 hunks)test/utils/export-map.spec.ts(4 hunks)test/utils/ignore.spec.ts(1 hunks)test/utils/import-type.spec.ts(1 hunks)test/utils/parse-stub-parser.cts(1 hunks)test/utils/parse-stub-parser.ts(0 hunks)test/utils/parse.spec.ts(10 hunks)test/utils/resolve.spec.ts(3 hunks)tsconfig.base.json(1 hunks)tsconfig.lib.json(1 hunks)tsconfig.staged.json(1 hunks)
💤 Files with no reviewable changes (6)
- test/utils/eslint-parser.ts
- .env.yarn
- .eslint-doc-generatorrc.mjs
- test/jest.serializer.ts
- .eslintignore
- test/utils/parse-stub-parser.ts
🧰 Additional context used
🧬 Code Definitions (46)
test/rules/no-relative-parent-imports.spec.ts (1)
test/utils.ts (3)
createRuleTestCaseFunctions(142-157)testFilePath(39-41)parsers(18-23)
src/rules/no-relative-packages.ts (16)
src/utils/create-rule.ts (1)
createRule(14-14)src/utils/module-visitor.ts (1)
ModuleOptions(14-19)src/rules/named.ts (1)
MessageId(8-8)src/rules/no-restricted-paths.ts (1)
MessageId(45-45)src/rules/namespace.ts (1)
MessageId(11-17)src/rules/no-absolute-path.ts (1)
MessageId(11-11)src/rules/no-cycle.ts (1)
MessageId(21-21)src/rules/no-import-module-exports.ts (1)
MessageId(49-49)src/rules/no-self-import.ts (1)
MessageId(10-10)src/rules/no-extraneous-dependencies.ts (1)
MessageId(355-360)src/rules/no-duplicates.ts (1)
MessageId(28-28)src/rules/extensions.ts (1)
MessageId(68-68)src/rules/dynamic-import-chunkname.ts (1)
MessageId(14-22)src/rules/first.ts (1)
MessageId(25-25)src/rules/group-exports.ts (1)
MessageId(38-38)src/rules/no-mutable-exports.ts (1)
MessageId(5-5)
test/rules/export.spec.ts (1)
test/utils.ts (1)
parsers(18-23)
src/rules/no-mutable-exports.ts (16)
src/rules/no-amd.ts (1)
MessageId(7-7)src/rules/newline-after-import.ts (1)
MessageId(83-83)src/rules/named.ts (1)
MessageId(8-8)src/rules/no-absolute-path.ts (1)
MessageId(11-11)src/rules/no-cycle.ts (1)
MessageId(21-21)src/rules/no-import-module-exports.ts (1)
MessageId(49-49)src/rules/no-named-as-default.ts (1)
MessageId(5-5)src/rules/no-self-import.ts (1)
MessageId(10-10)src/rules/no-extraneous-dependencies.ts (1)
MessageId(355-360)src/rules/no-useless-path-segments.ts (1)
MessageId(46-46)src/rules/no-duplicates.ts (1)
MessageId(28-28)src/rules/export.ts (1)
MessageId(111-111)src/rules/group-exports.ts (1)
MessageId(38-38)src/rules/extensions.ts (1)
MessageId(68-68)src/rules/no-dynamic-require.ts (1)
MessageId(37-37)src/rules/namespace.ts (1)
MessageId(11-17)
src/rules/no-relative-parent-imports.ts (2)
src/utils/create-rule.ts (1)
createRule(14-14)src/utils/module-visitor.ts (1)
ModuleOptions(14-19)
src/rules/no-default-export.ts (1)
src/utils/create-rule.ts (1)
createRule(14-14)
src/rules/no-amd.ts (16)
src/rules/no-mutable-exports.ts (1)
MessageId(5-5)src/rules/newline-after-import.ts (1)
MessageId(83-83)src/rules/no-absolute-path.ts (1)
MessageId(11-11)src/rules/no-import-module-exports.ts (1)
MessageId(49-49)src/rules/no-extraneous-dependencies.ts (1)
MessageId(355-360)src/rules/no-useless-path-segments.ts (1)
MessageId(46-46)src/rules/no-duplicates.ts (1)
MessageId(28-28)src/rules/named.ts (1)
MessageId(8-8)src/rules/no-cycle.ts (1)
MessageId(21-21)src/rules/no-named-as-default.ts (1)
MessageId(5-5)src/rules/no-self-import.ts (1)
MessageId(10-10)src/rules/no-dynamic-require.ts (1)
MessageId(37-37)src/rules/export.ts (1)
MessageId(111-111)src/rules/group-exports.ts (1)
MessageId(38-38)src/rules/extensions.ts (1)
MessageId(68-68)src/rules/dynamic-import-chunkname.ts (1)
MessageId(14-22)
src/rules/no-anonymous-default-export.ts (15)
src/rules/no-cycle.ts (2)
Options(15-19)MessageId(21-21)src/rules/no-unused-modules.ts (1)
Options(392-398)src/rules/namespace.ts (2)
Options(19-21)MessageId(11-17)src/rules/no-import-module-exports.ts (2)
Options(45-47)MessageId(49-49)src/rules/no-extraneous-dependencies.ts (2)
Options(344-353)MessageId(355-360)src/rules/extensions.ts (2)
Options(53-59)MessageId(68-68)src/rules/dynamic-import-chunkname.ts (2)
Options(8-12)MessageId(14-22)src/rules/no-commonjs.ts (1)
Options(15-15)src/rules/no-restricted-paths.ts (2)
Options(35-43)MessageId(45-45)src/rules/order.ts (1)
Options(1140-1152)src/rules/no-self-import.ts (1)
MessageId(10-10)src/rules/no-named-as-default.ts (1)
MessageId(5-5)src/rules/no-absolute-path.ts (1)
MessageId(11-11)src/rules/named.ts (1)
MessageId(8-8)src/rules/group-exports.ts (1)
MessageId(38-38)
test/node-resolver.spec.ts (1)
src/node-resolver.ts (1)
createNodeResolver(33-85)
src/rules/no-nodejs-modules.ts (7)
src/rules/no-unassigned-import.ts (1)
Options(29-31)src/rules/no-absolute-path.ts (1)
MessageId(11-11)src/rules/export.ts (1)
MessageId(111-111)src/rules/no-amd.ts (1)
MessageId(7-7)src/rules/no-named-as-default.ts (1)
MessageId(5-5)src/rules/no-self-import.ts (1)
MessageId(10-10)src/utils/create-rule.ts (1)
createRule(14-14)
src/rules/default.ts (17)
src/rules/export.ts (1)
MessageId(111-111)src/rules/group-exports.ts (1)
MessageId(38-38)src/rules/named.ts (1)
MessageId(8-8)src/rules/extensions.ts (1)
MessageId(68-68)src/rules/namespace.ts (1)
MessageId(11-17)src/rules/no-internal-modules.ts (1)
MessageId(41-41)src/rules/no-restricted-paths.ts (1)
MessageId(45-45)src/rules/no-unresolved.ts (1)
MessageId(21-21)src/rules/no-absolute-path.ts (1)
MessageId(11-11)src/rules/no-dynamic-require.ts (1)
MessageId(37-37)src/rules/no-cycle.ts (1)
MessageId(21-21)src/rules/no-import-module-exports.ts (1)
MessageId(49-49)src/rules/no-mutable-exports.ts (1)
MessageId(5-5)src/rules/no-named-as-default.ts (1)
MessageId(5-5)src/rules/no-self-import.ts (1)
MessageId(10-10)src/rules/no-extraneous-dependencies.ts (1)
MessageId(355-360)src/utils/create-rule.ts (1)
createRule(14-14)
src/rules/first.ts (2)
src/rules/no-absolute-path.ts (1)
MessageId(11-11)src/utils/create-rule.ts (1)
createRule(14-14)
src/rules/no-useless-path-segments.ts (2)
src/utils/module-visitor.ts (1)
ModuleOptions(14-19)src/utils/create-rule.ts (1)
createRule(14-14)
src/rules/no-self-import.ts (17)
src/rules/no-cycle.ts (1)
MessageId(21-21)src/rules/no-named-as-default.ts (1)
MessageId(5-5)src/rules/no-absolute-path.ts (1)
MessageId(11-11)src/rules/named.ts (1)
MessageId(8-8)src/rules/no-import-module-exports.ts (1)
MessageId(49-49)src/rules/no-extraneous-dependencies.ts (1)
MessageId(355-360)src/rules/no-useless-path-segments.ts (1)
MessageId(46-46)src/rules/no-duplicates.ts (1)
MessageId(28-28)src/rules/extensions.ts (1)
MessageId(68-68)src/rules/no-amd.ts (1)
MessageId(7-7)src/rules/group-exports.ts (1)
MessageId(38-38)src/rules/no-mutable-exports.ts (1)
MessageId(5-5)src/rules/namespace.ts (1)
MessageId(11-17)src/rules/export.ts (1)
MessageId(111-111)src/rules/no-dynamic-require.ts (1)
MessageId(37-37)src/rules/dynamic-import-chunkname.ts (1)
MessageId(14-22)src/utils/create-rule.ts (1)
createRule(14-14)
src/rules/order.ts (22)
src/rules/no-restricted-paths.ts (2)
Options(35-43)MessageId(45-45)src/rules/no-import-module-exports.ts (2)
Options(45-47)MessageId(49-49)src/rules/no-extraneous-dependencies.ts (2)
Options(344-353)MessageId(355-360)src/rules/no-unassigned-import.ts (1)
Options(29-31)src/rules/namespace.ts (2)
Options(19-21)MessageId(11-17)src/rules/no-internal-modules.ts (2)
Options(36-39)MessageId(41-41)src/rules/no-useless-path-segments.ts (2)
Options(42-44)MessageId(46-46)src/rules/no-duplicates.ts (2)
Options(23-26)MessageId(28-28)src/rules/dynamic-import-chunkname.ts (2)
Options(8-12)MessageId(14-22)src/rules/first.ts (2)
Options(23-23)MessageId(25-25)src/rules/newline-after-import.ts (2)
Options(77-81)MessageId(83-83)src/rules/no-commonjs.ts (1)
Options(15-15)src/rules/no-cycle.ts (2)
Options(15-19)MessageId(21-21)src/rules/consistent-type-specifier-style.ts (1)
Options(47-47)src/rules/no-unused-modules.ts (1)
Options(392-398)src/rules/extensions.ts (1)
Options(53-59)src/utils/create-rule.ts (1)
createRule(14-14)src/rules/group-exports.ts (1)
MessageId(38-38)src/rules/no-absolute-path.ts (1)
MessageId(11-11)src/rules/named.ts (1)
MessageId(8-8)src/rules/no-self-import.ts (1)
MessageId(10-10)src/rules/no-named-as-default.ts (1)
MessageId(5-5)
src/rules/max-dependencies.ts (18)
src/rules/no-dynamic-require.ts (2)
Options(33-35)MessageId(37-37)src/rules/no-import-module-exports.ts (2)
Options(45-47)MessageId(49-49)src/rules/no-extraneous-dependencies.ts (2)
Options(344-353)MessageId(355-360)src/rules/no-duplicates.ts (2)
Options(23-26)MessageId(28-28)src/rules/dynamic-import-chunkname.ts (2)
Options(8-12)MessageId(14-22)src/rules/no-commonjs.ts (1)
Options(15-15)src/rules/newline-after-import.ts (2)
Options(77-81)MessageId(83-83)src/rules/no-internal-modules.ts (2)
Options(36-39)MessageId(41-41)src/rules/no-nodejs-modules.ts (2)
Options(3-5)MessageId(7-7)src/rules/prefer-default-export.ts (1)
Options(5-7)src/rules/order.ts (1)
Options(1140-1152)src/rules/no-cycle.ts (2)
Options(15-19)MessageId(21-21)src/rules/extensions.ts (1)
Options(53-59)src/rules/no-absolute-path.ts (1)
MessageId(11-11)src/rules/no-amd.ts (1)
MessageId(7-7)src/rules/export.ts (1)
MessageId(111-111)src/rules/named.ts (1)
MessageId(8-8)src/rules/no-named-as-default.ts (1)
MessageId(5-5)
src/rules/no-duplicates.ts (11)
src/utils/lazy-value.ts (1)
lazy(4-16)src/rules/no-import-module-exports.ts (3)
Options(45-47)MessageId(49-49)ImportDeclaration(84-86)src/rules/no-cycle.ts (2)
Options(15-19)MessageId(21-21)src/rules/no-extraneous-dependencies.ts (2)
Options(344-353)MessageId(355-360)src/rules/no-unused-modules.ts (1)
Options(392-398)src/rules/no-dynamic-require.ts (2)
Options(33-35)MessageId(37-37)src/rules/no-commonjs.ts (1)
Options(15-15)src/rules/consistent-type-specifier-style.ts (3)
Options(47-47)ImportDeclaration(81-116)ImportDeclaration(122-269)src/rules/no-restricted-paths.ts (1)
Options(35-43)src/rules/no-absolute-path.ts (1)
MessageId(11-11)src/rules/no-named-default.ts (1)
ImportDeclaration(21-45)
src/rules/newline-after-import.ts (5)
src/rules/no-unassigned-import.ts (1)
Options(29-31)src/rules/order.ts (1)
Options(1140-1152)src/rules/no-restricted-paths.ts (1)
Options(35-43)src/rules/no-dynamic-require.ts (1)
Options(33-35)src/utils/create-rule.ts (1)
createRule(14-14)
src/node-resolver.ts (1)
src/types.ts (1)
NodeResolverOptions(37-41)
jest.config.ts (1)
test/utils.ts (2)
srcDir(236-236)testCompiled(234-234)
src/rules/export.ts (16)
src/rules/namespace.ts (1)
MessageId(11-17)src/rules/no-named-as-default.ts (1)
MessageId(5-5)src/rules/group-exports.ts (1)
MessageId(38-38)src/rules/named.ts (1)
MessageId(8-8)src/rules/extensions.ts (1)
MessageId(68-68)src/rules/no-absolute-path.ts (1)
MessageId(11-11)src/rules/no-dynamic-require.ts (1)
MessageId(37-37)src/rules/no-cycle.ts (1)
MessageId(21-21)src/rules/no-import-module-exports.ts (1)
MessageId(49-49)src/rules/no-mutable-exports.ts (1)
MessageId(5-5)src/rules/no-self-import.ts (1)
MessageId(10-10)src/rules/no-extraneous-dependencies.ts (1)
MessageId(355-360)src/rules/no-useless-path-segments.ts (1)
MessageId(46-46)src/rules/no-duplicates.ts (1)
MessageId(28-28)src/rules/no-amd.ts (1)
MessageId(7-7)src/rules/default.ts (1)
MessageId(5-5)
src/rules/no-absolute-path.ts (3)
src/rules/first.ts (1)
MessageId(25-25)src/utils/create-rule.ts (1)
createRule(14-14)src/utils/module-visitor.ts (1)
ModuleOptions(14-19)
src/rules/group-exports.ts (16)
src/rules/no-restricted-paths.ts (1)
MessageId(45-45)src/rules/namespace.ts (1)
MessageId(11-17)src/rules/named.ts (1)
MessageId(8-8)src/rules/extensions.ts (1)
MessageId(68-68)src/rules/export.ts (1)
MessageId(111-111)src/rules/no-cycle.ts (1)
MessageId(21-21)src/rules/no-import-module-exports.ts (1)
MessageId(49-49)src/rules/no-duplicates.ts (1)
MessageId(28-28)src/rules/no-absolute-path.ts (1)
MessageId(11-11)src/rules/no-self-import.ts (1)
MessageId(10-10)src/rules/no-extraneous-dependencies.ts (1)
MessageId(355-360)src/rules/no-useless-path-segments.ts (1)
MessageId(46-46)src/rules/no-mutable-exports.ts (1)
MessageId(5-5)src/rules/no-dynamic-require.ts (1)
MessageId(37-37)src/rules/no-named-as-default.ts (1)
MessageId(5-5)src/rules/no-amd.ts (1)
MessageId(7-7)
src/utils/legacy-resolver-settings.ts (1)
src/types.ts (9)
LegacyResolver(14-14)LegacyResolverResolve(22-22)LegacyResolverResolve(23-23)LegacyResolverResolveImport(25-25)LegacyResolverResolveImport(26-26)LegacyResolverObject(31-31)LegacyResolverObject(32-32)LegacyResolverRecord(28-28)LegacyResolverRecord(29-29)
src/rules/no-named-as-default.ts (16)
src/rules/no-cycle.ts (1)
MessageId(21-21)src/rules/no-self-import.ts (1)
MessageId(10-10)src/rules/export.ts (1)
MessageId(111-111)src/rules/no-absolute-path.ts (1)
MessageId(11-11)src/rules/named.ts (1)
MessageId(8-8)src/rules/no-import-module-exports.ts (1)
MessageId(49-49)src/rules/no-extraneous-dependencies.ts (1)
MessageId(355-360)src/rules/no-useless-path-segments.ts (1)
MessageId(46-46)src/rules/no-duplicates.ts (1)
MessageId(28-28)src/rules/no-amd.ts (1)
MessageId(7-7)src/rules/no-mutable-exports.ts (1)
MessageId(5-5)src/rules/namespace.ts (1)
MessageId(11-17)src/rules/no-dynamic-require.ts (1)
MessageId(37-37)src/rules/extensions.ts (1)
MessageId(68-68)src/rules/group-exports.ts (1)
MessageId(38-38)src/rules/dynamic-import-chunkname.ts (1)
MessageId(14-22)
test/rules/prefer-default-export.spec.ts (1)
test/utils.ts (1)
parsers(18-23)
src/rules/no-unassigned-import.ts (13)
src/rules/no-extraneous-dependencies.ts (1)
Options(344-353)src/rules/no-restricted-paths.ts (1)
Options(35-43)src/rules/no-import-module-exports.ts (1)
Options(45-47)src/rules/order.ts (1)
Options(1140-1152)src/rules/no-internal-modules.ts (1)
Options(36-39)src/rules/no-duplicates.ts (1)
Options(23-26)src/rules/dynamic-import-chunkname.ts (1)
Options(8-12)src/rules/newline-after-import.ts (1)
Options(77-81)src/rules/no-cycle.ts (1)
Options(15-19)src/rules/no-unused-modules.ts (1)
Options(392-398)src/rules/namespace.ts (1)
Options(19-21)src/rules/extensions.ts (1)
Options(53-59)src/utils/create-rule.ts (1)
createRule(14-14)
src/rules/no-restricted-paths.ts (22)
src/rules/order.ts (1)
Options(1140-1152)src/rules/no-extraneous-dependencies.ts (2)
Options(344-353)MessageId(355-360)src/rules/no-unassigned-import.ts (1)
Options(29-31)src/rules/namespace.ts (2)
Options(19-21)MessageId(11-17)src/rules/no-import-module-exports.ts (2)
Options(45-47)MessageId(49-49)src/rules/no-internal-modules.ts (2)
Options(36-39)MessageId(41-41)src/rules/consistent-type-specifier-style.ts (1)
Options(47-47)src/rules/no-cycle.ts (2)
Options(15-19)MessageId(21-21)src/rules/no-useless-path-segments.ts (2)
Options(42-44)MessageId(46-46)src/rules/no-duplicates.ts (2)
Options(23-26)MessageId(28-28)src/rules/extensions.ts (2)
Options(53-59)MessageId(68-68)src/rules/dynamic-import-chunkname.ts (2)
Options(8-12)MessageId(14-22)src/rules/first.ts (2)
Options(23-23)MessageId(25-25)src/rules/newline-after-import.ts (2)
Options(77-81)MessageId(83-83)src/rules/no-unused-modules.ts (1)
Options(392-398)src/rules/no-commonjs.ts (1)
Options(15-15)src/rules/group-exports.ts (1)
MessageId(38-38)src/rules/named.ts (1)
MessageId(8-8)src/rules/no-absolute-path.ts (1)
MessageId(11-11)src/rules/no-self-import.ts (1)
MessageId(10-10)src/rules/no-mutable-exports.ts (1)
MessageId(5-5)src/utils/create-rule.ts (1)
createRule(14-14)
test/rules/dynamic-import-chunkname.spec.ts (1)
test/utils.ts (1)
parsers(18-23)
test/rules/no-anonymous-default-export.spec.ts (1)
test/utils.ts (1)
parsers(18-23)
src/rules/exports-last.ts (1)
src/utils/create-rule.ts (1)
createRule(14-14)
src/rules/prefer-default-export.ts (20)
src/rules/consistent-type-specifier-style.ts (1)
Options(47-47)src/rules/no-rename-default.ts (2)
Options(14-16)MessageId(18-18)src/rules/no-import-module-exports.ts (2)
Options(45-47)MessageId(49-49)src/rules/no-duplicates.ts (2)
Options(23-26)MessageId(28-28)src/rules/dynamic-import-chunkname.ts (2)
Options(8-12)MessageId(14-22)src/rules/first.ts (2)
Options(23-23)MessageId(25-25)src/rules/no-dynamic-require.ts (2)
Options(33-35)MessageId(37-37)src/rules/no-cycle.ts (2)
Options(15-19)MessageId(21-21)src/rules/no-extraneous-dependencies.ts (2)
Options(344-353)MessageId(355-360)src/rules/no-useless-path-segments.ts (2)
Options(42-44)MessageId(46-46)src/rules/namespace.ts (2)
Options(19-21)MessageId(11-17)src/rules/newline-after-import.ts (2)
Options(77-81)MessageId(83-83)src/rules/no-internal-modules.ts (2)
Options(36-39)MessageId(41-41)src/rules/no-nodejs-modules.ts (2)
Options(3-5)MessageId(7-7)src/rules/no-unassigned-import.ts (1)
Options(29-31)src/rules/no-unused-modules.ts (1)
Options(392-398)src/rules/no-absolute-path.ts (1)
MessageId(11-11)src/rules/group-exports.ts (1)
MessageId(38-38)src/rules/export.ts (1)
MessageId(111-111)src/utils/create-rule.ts (1)
createRule(14-14)
src/rules/no-commonjs.ts (6)
src/rules/extensions.ts (2)
NormalizedOptions(61-66)Options(53-59)src/rules/no-extraneous-dependencies.ts (1)
Options(344-353)src/rules/no-duplicates.ts (1)
Options(23-26)src/rules/no-unassigned-import.ts (1)
Options(29-31)src/rules/no-cycle.ts (1)
Options(15-19)src/rules/no-anonymous-default-export.ts (1)
Options(113-122)
src/rules/no-dynamic-require.ts (25)
src/rules/no-import-module-exports.ts (2)
Options(45-47)MessageId(49-49)src/rules/no-extraneous-dependencies.ts (2)
Options(344-353)MessageId(355-360)src/rules/no-useless-path-segments.ts (2)
Options(42-44)MessageId(46-46)src/rules/no-duplicates.ts (2)
Options(23-26)MessageId(28-28)src/rules/no-cycle.ts (2)
Options(15-19)MessageId(21-21)src/rules/extensions.ts (2)
Options(53-59)MessageId(68-68)src/rules/dynamic-import-chunkname.ts (2)
Options(8-12)MessageId(14-22)src/rules/first.ts (2)
Options(23-23)MessageId(25-25)src/rules/newline-after-import.ts (1)
Options(77-81)src/rules/no-internal-modules.ts (1)
Options(36-39)src/rules/no-nodejs-modules.ts (1)
Options(3-5)src/rules/no-unassigned-import.ts (1)
Options(29-31)src/rules/prefer-default-export.ts (1)
Options(5-7)src/rules/order.ts (1)
Options(1140-1152)src/rules/consistent-type-specifier-style.ts (1)
Options(47-47)src/rules/max-dependencies.ts (1)
Options(5-8)src/rules/no-absolute-path.ts (1)
MessageId(11-11)src/rules/export.ts (1)
MessageId(111-111)src/rules/no-amd.ts (1)
MessageId(7-7)src/rules/named.ts (1)
MessageId(8-8)src/rules/no-named-as-default.ts (1)
MessageId(5-5)src/rules/no-self-import.ts (1)
MessageId(10-10)src/rules/group-exports.ts (1)
MessageId(38-38)src/rules/no-mutable-exports.ts (1)
MessageId(5-5)src/utils/create-rule.ts (1)
createRule(14-14)
src/rules/no-unused-modules.ts (8)
src/rules/no-cycle.ts (2)
Options(15-19)MessageId(21-21)src/rules/no-duplicates.ts (2)
Options(23-26)MessageId(28-28)src/rules/no-extraneous-dependencies.ts (2)
Options(344-353)MessageId(355-360)src/rules/no-unassigned-import.ts (1)
Options(29-31)src/rules/order.ts (1)
Options(1140-1152)src/rules/no-commonjs.ts (1)
Options(15-15)src/rules/export.ts (1)
MessageId(111-111)src/rules/named.ts (1)
MessageId(8-8)
src/rules/dynamic-import-chunkname.ts (7)
src/rules/no-cycle.ts (1)
Options(15-19)src/rules/no-unassigned-import.ts (1)
Options(29-31)src/rules/no-unused-modules.ts (1)
Options(392-398)src/rules/order.ts (1)
Options(1140-1152)src/rules/no-restricted-paths.ts (1)
Options(35-43)src/rules/prefer-default-export.ts (1)
Options(5-7)src/utils/create-rule.ts (1)
createRule(14-14)
src/rules/no-import-module-exports.ts (3)
src/types.ts (1)
RuleContext(130-135)src/utils/pkg-up.ts (1)
pkgUp(24-26)src/utils/create-rule.ts (1)
createRule(14-14)
test/utils/resolve.spec.ts (1)
src/types.ts (1)
NewResolver(63-68)
src/rules/consistent-type-specifier-style.ts (17)
src/rules/prefer-default-export.ts (1)
Options(5-7)src/rules/no-restricted-paths.ts (2)
Options(35-43)MessageId(45-45)src/rules/namespace.ts (2)
Options(19-21)MessageId(11-17)src/rules/no-cycle.ts (2)
Options(15-19)MessageId(21-21)src/rules/no-import-module-exports.ts (2)
Options(45-47)MessageId(49-49)src/rules/no-extraneous-dependencies.ts (2)
Options(344-353)MessageId(355-360)src/rules/no-duplicates.ts (2)
Options(23-26)MessageId(28-28)src/rules/extensions.ts (2)
Options(53-59)MessageId(68-68)src/rules/dynamic-import-chunkname.ts (2)
Options(8-12)MessageId(14-22)src/rules/newline-after-import.ts (2)
Options(77-81)MessageId(83-83)src/rules/no-unused-modules.ts (1)
Options(392-398)src/rules/order.ts (1)
Options(1140-1152)src/rules/named.ts (1)
MessageId(8-8)src/rules/no-absolute-path.ts (1)
MessageId(11-11)src/rules/no-self-import.ts (1)
MessageId(10-10)src/rules/group-exports.ts (1)
MessageId(38-38)src/utils/create-rule.ts (1)
createRule(14-14)
src/rules/no-extraneous-dependencies.ts (23)
src/rules/no-restricted-paths.ts (2)
Options(35-43)MessageId(45-45)src/rules/no-import-module-exports.ts (2)
Options(45-47)MessageId(49-49)src/rules/order.ts (1)
Options(1140-1152)src/rules/no-internal-modules.ts (2)
Options(36-39)MessageId(41-41)src/rules/no-useless-path-segments.ts (2)
Options(42-44)MessageId(46-46)src/rules/no-duplicates.ts (2)
Options(23-26)MessageId(28-28)src/rules/no-cycle.ts (2)
Options(15-19)MessageId(21-21)src/rules/extensions.ts (2)
Options(53-59)MessageId(68-68)src/rules/no-dynamic-require.ts (2)
Options(33-35)MessageId(37-37)src/rules/dynamic-import-chunkname.ts (2)
Options(8-12)MessageId(14-22)src/rules/first.ts (1)
Options(23-23)src/rules/newline-after-import.ts (1)
Options(77-81)src/rules/no-commonjs.ts (1)
Options(15-15)src/rules/consistent-type-specifier-style.ts (1)
Options(47-47)src/rules/no-unused-modules.ts (1)
Options(392-398)src/rules/no-absolute-path.ts (1)
MessageId(11-11)src/rules/named.ts (1)
MessageId(8-8)src/rules/no-self-import.ts (1)
MessageId(10-10)src/rules/no-named-as-default.ts (1)
MessageId(5-5)src/rules/no-amd.ts (1)
MessageId(7-7)src/rules/group-exports.ts (1)
MessageId(38-38)src/rules/no-mutable-exports.ts (1)
MessageId(5-5)src/utils/create-rule.ts (1)
createRule(14-14)
src/rules/namespace.ts (2)
src/types.ts (1)
RuleContext(130-135)src/utils/create-rule.ts (1)
createRule(14-14)
src/rules/no-cycle.ts (2)
src/utils/module-visitor.ts (1)
ModuleOptions(14-19)src/utils/export-map.ts (1)
DeclarationMetadata(42-47)
test/rules/consistent-type-specifier-style.spec.ts (1)
test/utils.ts (1)
parsers(18-23)
test/rules/order.spec.ts (1)
test/utils.ts (1)
parsers(18-23)
src/rules/extensions.ts (27)
src/rules/no-cycle.ts (2)
Options(15-19)MessageId(21-21)src/rules/no-import-module-exports.ts (2)
Options(45-47)MessageId(49-49)src/rules/no-extraneous-dependencies.ts (2)
Options(344-353)MessageId(355-360)src/rules/no-useless-path-segments.ts (2)
Options(42-44)MessageId(46-46)src/rules/no-duplicates.ts (2)
Options(23-26)MessageId(28-28)src/rules/no-dynamic-require.ts (2)
Options(33-35)MessageId(37-37)src/rules/consistent-type-specifier-style.ts (1)
Options(47-47)src/rules/no-restricted-paths.ts (2)
Options(35-43)MessageId(45-45)src/rules/dynamic-import-chunkname.ts (1)
Options(8-12)src/rules/first.ts (1)
Options(23-23)src/rules/namespace.ts (1)
Options(19-21)src/rules/newline-after-import.ts (1)
Options(77-81)src/rules/no-internal-modules.ts (1)
Options(36-39)src/rules/no-unassigned-import.ts (1)
Options(29-31)src/rules/no-unresolved.ts (1)
Options(16-19)src/rules/no-unused-modules.ts (1)
Options(392-398)src/rules/no-commonjs.ts (1)
NormalizedOptions(9-13)src/rules/named.ts (1)
MessageId(8-8)src/rules/group-exports.ts (1)
MessageId(38-38)src/rules/export.ts (1)
MessageId(111-111)src/rules/no-absolute-path.ts (1)
MessageId(11-11)src/rules/no-self-import.ts (1)
MessageId(10-10)src/rules/no-mutable-exports.ts (1)
MessageId(5-5)src/rules/no-named-as-default.ts (1)
MessageId(5-5)src/rules/no-amd.ts (1)
MessageId(7-7)src/rules/default.ts (1)
MessageId(5-5)src/utils/create-rule.ts (1)
createRule(14-14)
src/types.ts (2)
src/utils/import-type.ts (1)
ImportType(191-191)src/node-resolver.ts (1)
NodeResolverOptions(9-31)
🪛 GitHub Actions: CI
src/meta.ts
[warning] 6-6: "import.meta" is not available in the configured target environment ("es2015") and will be empty
eslint.config.js
[warning] 7-7: Caution: importPlugin also has a named export createNodeResolver. Check if you meant to write import {createNodeResolver} from 'eslint-plugin-import-x' instead import-x/no-named-as-default-member
[warning] 13-13: Caution: importPlugin also has a named export configs. Check if you meant to write import {configs} from 'eslint-plugin-import-x' instead import-x/no-named-as-default-member
src/utils/resolve.ts
[warning] 23-23: "import.meta" is not available in the configured target environment ("es2015") and will be empty
test/package.spec.ts
[error] 28-28: SyntaxError: The requested module 'eslint/use-at-your-own-risk' does not provide an export named 'FileEnumerator'
test/cli.spec.ts
[error] SyntaxError: The requested module 'eslint/use-at-your-own-risk' does not provide an export named 'LegacyESLint'
test/rules/no-unused-modules.spec.ts
[error] SyntaxError: The requested module 'eslint/use-at-your-own-risk' does not provide an export named 'FileEnumerator'
🔇 Additional comments (448)
patches/@swc-node+jest+1.8.13.patch (2)
9-10: Enhanced regex pattern to support additional module formats.The regex pattern has been expanded to include CommonJS (
.cts,.cjs) and ECMAScript Module (.mts,.mjs) file extensions, which aligns with the PR objective of migrating to ESM. This change improves compatibility with various module formats and ensures that all relevant file types are properly processed by the transformer.
16-17: Standardized return format for consistent interface.This change modifies the return value for non-matching files from returning the raw source string to returning an object with a
codeproperty containing the source. This creates a consistent interface regardless of whether a file matches the regex pattern or not, which is a good practice for API design.test/utils/export-map.spec.ts (3)
4-5: Update to ESM-compatible importsThe imports have been updated to align with ESM standards, using
@jest/globalsfor Jest and importingget-tsconfigas a namespace, which is appropriate for the migration to ESM.
7-7: Explicit .js extension added to import pathThe import path now includes the
.jsextension, which is required in ESM modules for proper resolution.
404-409:✅ Verification successful
Updated mocking approach for ESM compatibility
The code now uses
jest.unstable_mockModulewhich is appropriate for mocking in an ESM environment.Be aware that
jest.unstable_mockModuleis marked as unstable and may change in future Jest releases. Verify if there are any stable alternatives or migration plans:
🌐 Web query:
Is jest.unstable_mockModule still the recommended way to mock modules in Jest with ESM?💡 Result:
Yes,
jest.unstable_mockModuleremains the recommended approach for mocking ECMAScript Modules (ESM) in Jest, as confirmed by multiple 2024 sources. Here's a breakdown:Key Implementation Details
ESM-Specific Replacement:
Unlike CommonJS wherejest.mock()works, ESM requiresjest.unstable_mockModuledue to differences in module loading order[3][9]. Jest hoistsjest.mock()before imports in CommonJS, but this breaks with ESM's static imports[5][13].Required Workflow:
- Use
jest.unstable_mockModule('module-name', factoryFunction)to define mocks before dynamically importing the module under test[3][6][9].- Dynamically import mocked modules after setup using
await import()to ensure mocks apply[3][9].Example:
jest.unstable_mockModule('some-module', () => ({ foo: jest.fn() })); const { foo } = await import('some-module');TypeScript Considerations:
- Use type assertions or
jest.mocked()for type safety:const mockFoo = foo as jest.MockedFunction<typeof foo>; // or (Jest 27+) const mockFoo = jest.mocked(foo);- Add TypeScript declarations for
unstable_mockModuleif needed[9].Why It’s Still "Unstable"
- The "unstable" label reflects Jest’s experimental ESM support, not reliability[3][10]. The API has been functional since Jest 27 (2021) but hasn’t been renamed due to ongoing ESM integration work[10][13].
- Alternatives like
jest.createMockFromModuleexist for manual mocks but require more boilerplate[5].Key Differences vs. CommonJS
Feature CommonJS ( jest.mock)ESM ( jest.unstable_mockModule)Hoisting Automatic None – mocks must be defined first[9] Imports Static ( require)Dynamic ( await import())[3][9]Module Replacement Full overrides Partial mocking via factory[2][5] For projects using Jest ≥27,
unstable_mockModuleis the only viable ESM mocking solution as of 2025[3][6][9]. While third-party tools like@atcodes/mockableexist[8], they add complexity compared to native Jest APIs.Citations:
- 1: https://dev.to/mattiz/mock-modules-properly-with-jest-and-typescript-3nao
- 2: https://www.bitovi.com/blog/mocking-modules-in-jest-tests
- 3: https://dev.to/vinhyan/a-guide-to-setting-up-jest-for-javascript-testing-with-esm-22m6
- 4: https://dev.to/bregwin/testing-troubles-with-jest-and-esm-and-how-to-fix-it-pae
- 5: https://jestjs.io/docs/manual-mocks
- 6: https://world.hey.com/michael.weiner/developer-from-the-future-1-mock-ing-third-party-libraries-in-an-esm-with-jest-unstable-mocking-4741561e
- 7: jest.mock does not mock an ES module without Babel jestjs/jest#10025
- 8: https://adamtuttle.codes/blog/2024/mocking-esm-dependencies-for-tests/
- 9: https://blog.revathskumar.com/2024/07/jest-module-mocking-in-es-modules.html
- 10: https://www.sitepen.com/blog/jest-esm-almost-there
- 11: https://jestjs.io/docs/next/configuration
- 12: [Bug]: jest.mock not working with ESM support activated jestjs/jest#13135
- 13: https://jestjs.io/docs/ecmascript-modules
- 14: https://javascript.plainenglish.io/mock-modules-using-jest-bcbad3b803b0
Approval: ESM Module Mocking Verified
The updated code in
test/utils/export-map.spec.ts(lines 404-409) now correctly employsjest.unstable_mockModulefor mocking in an ESM environment. Recent web sources confirm that, despite the "unstable" label, it remains the recommended approach for Jest with ESM, and no stable alternative has emerged yet.
- The implementation mirrors the current best practices for ESM module mocking.
- The note about its “unstable” status is duly acknowledged, so continue to monitor Jest updates in the future.
index.d.cts (1)
1-3: Validate ESM vs. CJS usage in.cts
This file bridges an ES module import to a CommonJS export. It can be useful for backward compatibility, but verify it aligns with your larger ESM migration strategy. If purely ESM is desired, consider switching to an ESM export style (e.g.,export default), unless you intentionally need a CJS fallback.test/utils/parse-stub-parser.cts (1)
1-6: Beware potential concurrency side effects
Theparsevariable is reassigned at runtime, which may cause unpredictable test results if tests run in parallel. Consider using an isolated or factory-based approach to avoid shared mutable state..github/workflows/codeql.yml (1)
4-5: Confirm workflow trigger disabling
Setting bothpushandpull_requesttonullprevents this workflow from running on code changes. If this is intentional and you only want scheduled scans, no action is needed. Otherwise, revert them to re-enable triggers.eslint.config.js (3)
1-16: Address pipeline warnings about import usage
The pipeline warns aboutimportPluginalso having named exports (e.g.,createNodeResolver). Confirm if you need to import them explicitly. Otherwise, this import setup looks fine for your ESM migration.🧰 Tools
🪛 GitHub Actions: CI
[warning] 7-7: Caution:
importPluginalso has a named exportcreateNodeResolver. Check if you meant to writeimport {createNodeResolver} from 'eslint-plugin-import-x'instead import-x/no-named-as-default-member
[warning] 13-13: Caution:
importPluginalso has a named exportconfigs. Check if you meant to writeimport {configs} from 'eslint-plugin-import-x'instead import-x/no-named-as-default-member
17-20: Eslint version check
This logic correctly determines whether ESLint is v9 or higher. No objections here.
21-186: Overall ESLint configuration
- The layered approach with multiple flat configs and plugin rules looks coherent.
- Specifying
ecmaVersion: 2020is valid, though you might consider bumping to a newer version if you plan to fully leverage modern ESM features.- The selective ignoring of test/fixtures and coverage directories is typical, but double-check that ignoring
CHANGELOG.mddoes not block relevant lint rules from catching potential textual errors.- The extra cjs/cts block is good for enabling Node globals.
Everything else appears consistent with your ESM migration.
jest.config.ts (5)
1-1: Package replacement for better ESM compatibilityThe import source has been changed from
@swc/coreto@swc-node/coreto better support the ESM migration process.
12-13: Enhanced module resolution for ESM migrationTwo key improvements in the module mapper:
- Added pattern to resolve
.jsand.cjsextensions to their base files- Updated the plugin mapping to dynamically choose between
.cjsand.tsextensions based on test environmentThese changes are necessary for proper module resolution when working with both ESM and CommonJS files.
17-17: Updated serializer path to CommonJS formatThe snapshot serializer path has been updated to use the CommonJS extension (
.cjs), which ensures Jest can properly load the serializer in an ESM environment.
20-27: Enhanced transform configuration for mixed module formatsThe transform configuration has been improved to:
- Handle a wider range of file extensions including
.mjs- Explicitly set
module: 'es6'for ESM processing- Add a separate transform rule for CommonJS files (
.cjs)These changes ensure Jest can properly process both ESM and CommonJS files during testing.
28-28: Added explicit ESM file extension configurationThe new
extensionsToTreatAsEsmsetting explicitly tells Jest which file extensions should be processed as ES modules, which is crucial for proper module handling in a mixed module environment..eslintrc.cjs (7)
1-2: Clarified file purpose with explanatory commentThe added comment clearly states that this file exists specifically for testing the
no-unused-modulesrule, which helps explain its presence in an ESM-focused codebase.
5-7: Updated condition variables for ESLint version and test modeTwo important changes:
- Renamed and inverted the logic from
nonLatestEslinttonoEslintrc(true when ESLint version > 8)- Added
testCompiledvariable to detect if tests are running against compiled codeThese variables allow for conditional rule application based on environment context.
19-20: Conditional plugin inclusion based on environmentMade ESLint plugin inclusion conditional:
plugin:import-x/recommendedonly included when running against compiled codeplugin:unicorn/recommendedonly included when using older ESLint versions- Added
.filter(Boolean)to remove any falsy values from the extends arrayThis provides appropriate linting configurations for different environments and module formats.
Also applies to: 23-24, 27-27
41-41: Inverted rule condition to match renamed variableThe condition for the
no-constant-conditionrule has been inverted to align with the renamed and invertednoEslintrcvariable, maintaining the same logical behavior.
59-67: Refactored rule configuration with conditional spread operatorThe
unicorn/filename-caserule configuration has been refactored to use a spread operator with a conditional check onnoEslintrc, providing a more modern and concise approach to conditionally including rule settings.
77-88: Made import-related rules conditional based on test environmentImport-related rules are now conditionally applied only when running tests against compiled code (
testCompiled):
import-x/no-extraneous-dependenciesimport-x/unambiguousThis prevents potential issues when testing different module formats.
116-127: Conditionally applied additional import rules for TypeScript filesAdditional import rules for TypeScript files are now conditionally applied based on the
testCompiledflag:
import-x/consistent-type-specifier-styleimport-x/orderwith alphabetical sorting and spacing requirementsThis ensures consistent import formatting when working with compiled code.
test/fixtures/tsconfig.json (1)
1-7: Added TypeScript configuration for test fixturesThis new configuration file provides settings necessary for handling ESM in test fixtures:
- Extends the Node.js TypeScript base configuration
- Enables JavaScript processing with
allowJs: true- Disables
verbatimModuleSyntaxto allow more flexible module syntax processingThese settings ensure that test fixtures can properly work with both ESM and CommonJS code during the migration process.
src/utils/import-declaration.ts (1)
4-4: Added explicit file extension for ESM compatibilityThe import path has been updated to include the
.jsextension, which is required for proper module resolution in ESM. Unlike CommonJS, ESM requires explicit file extensions in import paths for clarity and reliable resolution.tsconfig.lib.json (1)
1-4: New Configuration Setup intsconfig.lib.json
This file correctly extends the base configuration and excludes the "test" directory from compilation. It ensures that library builds remain streamlined.src/utils/static-require.ts (1)
3-3: Comment Formatting Consistency
Updating the comment from// todo:to// TODO:adheres to standard conventions and improves readability.tsconfig.staged.json (1)
1-6: Staged TypeScript Configuration Verification
This new configuration file appropriately extends the base configuration and setsverbatimModuleSyntaxto false. This change aids in ensuring compliant module syntax handling during staged builds.test/jest.serializer.cjs (1)
1-5: Jest Serializer in CommonJS Format
The file is correctly set up for snapshot serialization using CommonJS (.cjs). This is acceptable if your Jest configuration or related tooling requires a CommonJS serializer. Just ensure that this coexistence with the ESM migration is explicitly documented or configured in your testing setup.src/utils/pkg-dir.ts (1)
3-3: Explicit File Extension in Import
Updating the import to./pkg-up.jsaligns with the ESM migration strategy and clarifies module resolution during runtime.test/index.js (1)
1-2: Explicit Export Path in ESM Module
The change updates the export to explicitly reference./fixtures/index.js, which is in line with ESM requirements and improves clarity regarding the actual module being exported.test/utils/ignore.spec.ts (2)
1-2: Explicit File Extension for Utility Imports
Updating the import oftestContextto use../utils.jsensures correct module resolution under ESM. This change is consistent with the ESM migration approach.
3-104: Validation of Test Cases and Import Consistency
The remainder of the file (lines 3–104) appears to have no logic changes apart from ensuring that all import paths remain correct with explicit file extensions. The test cases for functions likeisIgnored,hasValidExtension, andgetFileExtensionsremain intact and well-organized, validating both default behavior and custom configurations.src/config/flat/warnings.ts (2)
1-4: Updated Type Import with Explicit Extension
Changing the import path forPluginFlatBaseConfigto include.jsis a necessary step for proper ESM resolution. This update is applied consistently across configuration files in the project.
6-13: ESM Export Syntax Transition
Switching from CommonJS-style exports toexport defaultis a correct and modern approach under ESM. The use of thesatisfiesoperator to enforce the configuration type is a nice touch for maintaining type safety.src/config/flat/electron.ts (2)
1-2: Consistent Import of Type Definitions
UpdatingPluginFlatConfigimport to include the.jsextension aligns with the overall migration strategy and ensures consistent module resolution in an ESM environment.
3-11: Transition to ESM Export
Changing the export from CommonJS’sexport =to ES Module’sexport defaultmodernizes the configuration and aids in better interoperability. The use of thesatisfiesoperator again reinforces type safety.src/utils/read-pkg-up.ts (2)
5-6: Explicit Import Path forpkgUpFunction
Updating the import toimport { pkgUp } from './pkg-up.js'ensures that the module is correctly resolved by the ESM loader. This small but important change contributes to overall consistency in the codebase’s module resolution strategy.
7-31: Robust Package JSON Reader Implementation
The rest of the file shows a clear and concise implementation for reading the package.json file. The function handles BOM stripping, parses JSON into a typed object, and gracefully returns an empty object on failure. This error-handling approach is simple yet effective for the intended use case.src/config/flat/recommended.ts (1)
1-1: ESM Import Extension Update
The import now explicitly includes the “.js” extension forPluginFlatBaseConfig, which is essential for proper module resolution under ESM.test/rules/no-webpack-loader-syntax.spec.ts (1)
3-3: Updated Utility Import with Extension
The change to include “.js” in the import path forcreateRuleTestCaseFunctionsensures that module resolution is explicit and consistent with the ESM migration strategy.src/utils/declared-scope.ts (1)
3-3: Consistent ESM Import for Types
Updating the import ofRuleContextto include the “.js” extension aligns with the migration to ESM and maintains consistency across the codebase.src/config/flat/stage-0.ts (2)
1-1: Explicit File Extension in Import
The update from'../../types'to'../../types.js'for importingPluginFlatBaseConfigis correct and necessary for clear module resolution in an ESM environment.
8-12: Adoption of ESM Default Export
Switching from a CommonJS-style export to usingexport default(with the TypeScriptsatisfiesoperator) is a key step in the migration. This change improves type safety and ESM compatibility.src/utils/package-path.ts (1)
3-6: Updated Import Paths with Explicit Extensions
The modifications to the import statements on lines 3, 5, and 6—updating them to include “.js” forRuleContext,pkgUp, andreadPkgUprespectively—are consistent with the overall ESM migration effort. This explicitness avoids ambiguity during module resolution.src/config/flat/react-native.ts (2)
1-1: LGTM: Import path updated to include.jsextensionThe import statement has been updated to include the
.jsextension which is consistent with ES Module requirements for explicit file extensions in import paths. This change aligns with the PR's objective of migrating to ESM as the primary module system.
6-15: LGTM: Using ES Module export syntaxThe export statement uses ES Module syntax with the TypeScript
satisfiesoperator, correctly implementing the configuration for React Native. This is properly typed with thePluginFlatBaseConfiginterface.test/rules/extensions.spec.ts (1)
3-3: LGTM: Import path updated to include.jsextensionThe import statement has been updated to include the
.jsextension, which is necessary for ESM compatibility. This change aligns with the PR's objective of migrating to ESM as the primary module system.src/utils/ignore.ts (1)
5-10: LGTM: Import path updated to include.jsextensionThe import statement has been updated to include the
.jsextension, which is necessary for ESM compatibility. This change aligns with the PR's objective of migrating to ESM as the primary module system..eslint-doc-generatorrc.js (2)
1-11: LGTM: New ESLint document generator configuration using ES modulesThis new configuration file for the ESLint documentation generator properly uses ES Module syntax for imports and exports, aligning with the PR's objective of migrating to ESM.
3-3: Consider adding.jsextension to prettierRC import pathFor consistency with the other imports in this PR that have been updated to include
.jsextensions, consider adding the.jsextension to the import path for the prettierRC configuration.-import prettierRC from './.prettierrc.js' +import prettierRC from './.prettierrc.js.js'On second thought, this is likely incorrect. The file itself already has a
.jsextension in its name (.prettierrc.js), so adding another.jswould create a file with two extensions (.prettierrc.js.js). The current import is correct.src/config/flat/typescript.ts (1)
1-1: Correct update for ESM compatibilityThe addition of the
.jsextension to the import path is necessary for ESM compatibility, as ESM requires explicit file extensions for module resolution.src/config/react.ts (2)
1-1: Correct addition of file extension for ESM compatibilityAdding the
.jsextension to the import path is necessary for ESM module resolution, which requires explicit file extensions.
10-10: Proper export syntax for ESMGood conversion from CommonJS
export =to ESMexport default. This is a necessary change since ESM doesn't support the CommonJS export syntax.src/config/flat/errors.ts (1)
1-1: Correct update for ESM compatibilityThe addition of the
.jsextension to the import path is necessary for ESM compatibility, which requires explicit file extensions for proper module resolution.test/tsconfig.json (1)
2-5: Consider the implications of disabling verbatimModuleSyntaxSetting
"verbatimModuleSyntax": falsewill give more flexibility with import/export syntax during the ESM migration, but it reduces type safety by allowing potentially ambiguous imports.Is this intended to be a permanent configuration specifically for tests, or a temporary measure to ease the transition? If permanent, consider documenting the reason for this exception in the test environment.
src/utils/module-visitor.ts (1)
14-14: Good migration from type to interface for better future extensibilityChanging
ModuleOptionsfrom a type alias to an interface is a positive change as part of the ESM migration. Interfaces support declaration merging and can be extended by other declarations, which will be beneficial for future enhancements.test/rules/group-exports.spec.ts (3)
1-1: Good addition of cjsRequire for CommonJS compatibilityAdding
cjsRequirefrom@pkgr/coreis a necessary step for the ESM migration, as it allows using CommonJS-style require in an ESM context.
4-4: Correct addition of .js extension for ESM compatibilityAdding the
.jsextension to the import path is required for ESM module resolution, as ESM doesn't support extensionless imports like CommonJS does.
10-10: Good replacement of require with cjsRequireReplacing the direct use of
requirewithcjsRequireis necessary for ESM compatibility, as the nativerequirefunction is not available in ESM context.test/rules/no-self-import.spec.ts (1)
3-3: Correct addition of .js extension for ESM compatibilityAdding the
.jsextension to the import path is required for ESM module resolution, as ESM doesn't support extensionless imports like CommonJS does.test/rules/no-import-module-exports.spec.ts (1)
6-6: Correct addition of .js extension for ESM compatibilityAdding the
.jsextension to the import path is required for ESM module resolution, as ESM doesn't support extensionless imports like CommonJS does.test/rules/no-namespace.spec.ts (1)
3-3: Looks good - extension added to import path for ESM compatibility.The addition of the
.jsextension to the import path is a necessary change for proper ESM compatibility, matching the migration goal outlined in the PR objectives.test/utils/import-type.spec.ts (1)
3-3: Looks good - import path updated for ESM compatibility.The
.jsextension was added to the import path as required for ESM modules, which aligns with the PR objective of migrating to ESM as the primary module system.src/config/flat/react.ts (1)
1-1: Looks good - import path updated for ESM compatibility.The
.jsextension was added to the import path as required for ESM modules, which aligns with the PR objective of migrating to ESM as the primary module system.test/rules/no-unassigned-import.spec.ts (1)
5-5: Good update to include the file extension!This change correctly adds the
.jsextension to the import path, which is a requirement when migrating to ECMAScript Modules (ESM). In ESM, relative imports must include file extensions for proper module resolution.test/rules/no-empty-named-blocks.spec.ts (2)
1-1: Great approach using cjsRequire for backward compatibility!Using
cjsRequirefrom '@pkgr/core' is an excellent solution to handle the dynamic imports that were previously using CommonJSrequire(). This maintains compatibility with existing code patterns while moving forward with the ESM migration.
5-5: Properly updated import with .js extensionThe import path has been correctly updated to include the
.jsextension as required by ESM.src/rules/imports-first.ts (3)
1-1: Updated import path with explicit file referenceThe import path has been correctly updated to include the
.jsextension with a specific reference to the index file, which is necessary for ESM compatibility.
3-3: Added file extension to local importThe local import has been correctly updated to include the
.jsextension as required by ESM.
5-5: Updated export syntax for ESM compatibilityChanged from CommonJS-style
export =to the standard ESMexport defaultsyntax, which is a necessary part of the migration to ESM as the primary module system.test/rules/no-deprecated.spec.ts (1)
9-10: Correctly updated import paths with file extensionsBoth the regular import path and the type import path have been updated to include the
.jsextension, which is required for proper module resolution in an ESM environment.src/utils/docs-url.ts (1)
5-5: LGTM: Function signature updated correctlyThe function signature update to use the imported version variable is correct and aligns with the ESM migration.
test/rules/no-rename-default.spec.ts (1)
5-6: LGTM: Import paths correctly include .js extensionThe import paths have been properly updated to include .js extensions, which is necessary for ESM compatibility.
test/rules/unambiguous.spec.ts (3)
1-1: LGTM: Proper addition of cjsRequire importAdding the
cjsRequireimport is an appropriate approach for handling CommonJS modules in an ESM context.
4-4: LGTM: Import path correctly includes .js extensionThe import path has been properly updated to include the .js extension, which is necessary for ESM compatibility.
69-69: LGTM: Correctly replaced require with cjsRequireReplacing
requirewithcjsRequireis the right approach when working with CommonJS modules in an ESM context.test/rules/exports-last.spec.ts (1)
5-6: LGTM: Import paths correctly include .js extensionThe import paths have been properly updated to include .js extensions, which is necessary for ESM compatibility.
test/rules/no-relative-packages.spec.ts (1)
6-7: Import paths updated correctly for ESM compatibilityThe addition of
.jsfile extensions to import paths is necessary for ESM module compatibility. This change aligns perfectly with the migration goals.test/rules/no-nodejs-modules.spec.ts (1)
4-5: Import paths correctly updated for ESM complianceThe explicit
.jsfile extensions added to import paths are necessary for proper ESM module resolution. This change is consistent with the migration strategy.test/rules/no-restricted-paths.spec.ts (1)
4-5: Import paths correctly updated with file extensionsThe addition of
.jsfile extensions to import paths is correctly implemented for ESM compatibility. This change follows the same pattern as in other test files, ensuring a consistent approach to the migration.src/rules/no-relative-parent-imports.ts (2)
3-10: Import paths correctly updated for ESM with proper module resolutionThe import paths have been updated to include the
.jsextension and explicitly reference the index file in the utils directory. This ensures proper module resolution in an ESM environment.
14-14: Export syntax updated from CommonJS to ESMThe export statement has been changed from
export =(CommonJS) toexport default(ESM), which is a necessary part of the ESM migration. This changes how the module is exported and will affect how it's imported in other files.test/rules/no-relative-parent-imports.spec.ts (3)
1-1: Added cjsRequire for ECMAScript Modules compatibilityThe addition of
cjsRequirefrom@pkgr/coreis part of the migration to ESM, providing a way to use CommonJS-style require in an ESM context.
5-6: Updated import paths with .js extensionAdding explicit
.jsfile extensions to import paths is required for ESM module resolution, which doesn't support automatic extension resolution like CommonJS.
14-14: Replaced require with cjsRequireChanged from
require(parsers.BABEL)tocjsRequire(parsers.BABEL)to maintain compatibility with the parser loading in an ESM context.test/rules/no-internal-modules.spec.ts (1)
4-5: Updated import paths with .js extensionAdding explicit
.jsfile extensions to import paths is required for ESM module resolution, which doesn't support automatic extension resolution like CommonJS.test/rules/no-named-export.spec.ts (2)
1-1: Added cjsRequire aliased as requireImporting
cjsRequireasrequireprovides a clean way to maintain compatibility with existing code that uses therequirefunction while migrating to ESM.
5-5: Updated import paths with .js extensionAdding explicit
.jsfile extensions to import paths is required for ESM module resolution, which doesn't support automatic extension resolution like CommonJS.src/rules/order.ts (4)
19-19: Updated import path with .js extensionAdding explicit
.jsfile extensions to import paths is required for ESM module resolution.
20-25: Updated utility imports with .js extensionAdding explicit
.jsfile extensions to utility import paths is part of the ESM migration.
1140-1152: Changed type to exported interfaceConverting
type Optionstoexport interface Optionsmakes the type definition exportable for other modules to use and enables potential interface merging if needed.
1164-1164: Updated to ESM-style default exportChanged from CommonJS-style
export =to ESM-styleexport defaultto align with ECMAScript Modules syntax..github/workflows/ci.yml (4)
25-27: Updated ESLint version format and added version 9 testingThe ESLint version format has been changed from strings to numbers, and ESLint version 9 has been added to the test matrix. This future-proofs the CI pipeline by ensuring compatibility with upcoming ESLint releases.
47-47: Conditionally skip ESLint 9 installationGood addition to skip the explicit installation for ESLint 9, which suggests that the workflow is prepared for handling ESLint 9 differently than previous versions.
49-49: Added eslint-plugin-unicorn to installation stepThe ESLint installation step now includes
eslint-plugin-unicorn@56alongside the ESLint version. This ensures consistent dependency versions across all test environments.
55-55: Simplified build and test command using run-sThe build and test step has been simplified by using
yarn run-sto run the tests sequentially. This is cleaner and more maintainable than a multi-line command.src/config/warnings.ts (2)
1-1: Updated import path with .js extensionThe import path now includes the
.jsextension, which is required for ECMAScript Modules (ESM) resolution. This is consistent with the PR objective to migrate to ESM as the primary module system.
6-6: Changed export syntax from CommonJS to ESM styleThe export syntax has been updated from CommonJS-style
export =to ESM-styleexport default. This is a necessary change for ESM compatibility and aligns with the migration goals.src/utils/parse.ts (2)
12-12: Updated import path with .js extension for typesThe import path for types now includes the
.jsextension, which is required for proper module resolution in ECMAScript Modules (ESM).
14-14: Updated import path with .js extension for module-requireThe import path for
moduleRequirenow includes the.jsextension, maintaining consistency with ESM requirements for explicit file extensions in import paths.src/utils/source-type.ts (2)
1-1: Switched to using TSESLint types directlyThe import has been changed to use
TSESLintfrom@typescript-eslint/utilsinstead of a localRuleContexttype. This improves type consistency by using the official TypeScript-ESLint utility types.
3-6: Enhanced function signature with generics and changed to named exportThe function has been converted from a default export to a named export and enhanced with generic type parameters, improving type safety. The context parameter now uses
TSESLint.RuleContext<MessageIds, Options>which provides better type checking for rule implementations.This change is part of the ESM migration strategy and enhances the type system while maintaining the same functionality.
src/config/errors.ts (2)
1-1: File extension added to import path is correct for ESMAdding the
.jsextension to the import path is necessary for ES modules, as they require explicit file extensions unlike CommonJS modules.
7-7: Migration from CommonJS to ESM export syntaxThe change from
export = {toexport default {correctly transitions this module from CommonJS to ESM export syntax, aligning with the PR's objective to migrate to ESM as the primary module system.src/config/react-native.ts (2)
1-1: File extension added to import path is correct for ESMAdding the
.jsextension to the import path is necessary for ES modules, as they require explicit file extensions unlike CommonJS modules.
6-6: Migration from CommonJS to ESM export syntaxThe change from
export = {toexport default {correctly transitions this module from CommonJS to ESM export syntax, aligning with the PR's objective to migrate to ESM as the primary module system.src/utils/module-require.ts (5)
4-5: Replacing native require with cjsRequire from @pkgr/coreThe introduction of
cjsRequirefrom@pkgr/coreis a good approach for handling CommonJS-style requires in an ESM environment. This will help maintain compatibility with existing code while migrating to ESM.
17-18: Replaced require.resolve with cjsRequire.resolveCorrectly replaced
require.resolvewithcjsRequire.resolveto maintain the same functionality in the ESM context.
20-23: Updated module resolution to use cjsRequireThis change properly updates the module resolution logic to use
cjsRequireinstead of the nativerequire, which is necessary for ESM compatibility while maintaining the ability to dynamically resolve and load modules.
30-30: Updated require.main.require to cjsRequire.main.requireCorrectly replaced
require.main.requirewithcjsRequire.main!.requireto maintain the fallback resolution strategy in the ESM context.
36-36: Final fallback updated to use cjsRequireThe final fallback now uses
cjsRequire(p)instead ofrequire(p), completing the consistent replacement of require calls throughout this utility function.src/rules/no-named-export.ts (2)
1-1: Updated and consolidated import with .js extensionThe import statement now correctly includes the
.jsextension and consolidates multiple utility imports into a single import statement. This is both cleaner and necessary for ESM compatibility.
3-3: Migration from CommonJS to ESM export syntaxThe change from
export = createRule({toexport default createRule({correctly transitions this module from CommonJS to ESM export syntax, aligning with the PR's objective to migrate to ESM as the primary module system.src/rules/no-mutable-exports.ts (3)
3-3: Clean import path update for ESM.The explicit
.jsextension is required for ESM compatibility.
5-5: Good type export pattern.Explicitly exporting the MessageId type aligns with the consistent pattern applied across all rule files and improves type accessibility.
7-7: Proper conversion to ESM default export.Converting from CommonJS
export =to ESMexport defaultis the correct approach for ESM migration.src/config/stage-0.ts (2)
1-1: Updated import path for ESM compatibility.The explicit
.jsextension in the import statement is necessary for ESM modules.
8-8: Correct migration to ESM export syntax.Changing from CommonJS
export =to ESMexport defaultproperly aligns with the ESM migration.src/config/electron.ts (3)
1-1: Updated import path for ESM compatibility.The explicit
.jsextension in the import statement properly supports ESM module resolution.
6-6: Correct migration to ESM export syntax.Converting from CommonJS
export =to ESMexport defaultis appropriate for ESM migration.
10-10: Good use of 'satisfies' operator.Using
satisfies PluginConfiginstead ofas PluginConfigis a better TypeScript practice as it verifies type compatibility while preserving the object's inferred type.test/utils/eslint-parser.cts (4)
1-5: Mock parser implementation for testing.Creating a minimal mock parser that returns an empty AST is useful for testing. Using a
.ctsextension maintains CommonJS compatibility for testing purposes while the main codebase migrates to ESM.
7-9: Good testing utility for dynamic parser configuration.The setter function provides flexibility for tests to customize the parser behavior as needed.
11-11: Potential issue with uninitialized function.The
parsevariable is declared as a function type but not initialized. This could cause runtime errors if used beforesetParseis called.Consider initializing it with a default implementation or adding runtime checks:
-export let parse: () => void +export let parse: () => void = () => { + throw new Error('Parse function not initialized') +}
13-15: Proper setter implementation.The setter function correctly assigns the new implementation to the mutable
parsevariable.src/config/recommended.ts (2)
1-1: Proper file extension added for ESM compatibilityAdding the
.jsextension to the import path is a necessary change for ESM compatibility, as ESM requires explicit file extensions for relative imports.
6-6: Export statement updated to use ESM syntaxThe change from CommonJS
export =to ESMexport defaultis appropriate for the migration to ECMAScript modules as the primary module system.src/rules/unambiguous.ts (2)
5-5: Import path updated with .js extension for ESM compatibilityThe import statement now correctly includes the
.jsextension and imports all utilities from the index file, which is consistent with ESM requirements.
7-7: Export statement migrated to ESM syntaxChanging from CommonJS
export =to ESMexport defaultis appropriate for the migration to ECMAScript modules.test/rules/max-dependencies.spec.ts (3)
1-1: Added CommonJS compatibility for testsImporting
cjsRequirefrom@pkgr/coreis a good solution for maintaining compatibility with existing test code that uses CommonJSrequire()calls while migrating to ESM.
4-4: Import path updated with .js extensionThe addition of the
.jsextension to the import path is necessary for ESM compatibility and consistent with the overall migration strategy.
79-79: Compatible require usage in testsThe
require()function is correctly used with the importedcjsRequirealias, ensuring that the CommonJS module loading works properly within the ESM context of the tests.Also applies to: 90-90
src/rules/no-named-as-default-member.ts (2)
7-7: Import path updated for ESM compatibilityThe import path now correctly includes the
.jsextension and explicitly references the index file, which is necessary for proper module resolution in ESM.
11-11: Export statement updated to ESM syntaxChanging from CommonJS
export =to ESMexport defaultis appropriate for the migration to ECMAScript modules.src/rules/default.ts (3)
3-3: ESM path update looks goodThe import path now includes the
.jsextension which is required for ESM modules. This is consistent with other files in the codebase as part of the migration to ESM.
5-5: Appropriate export of MessageId typeMaking the
MessageIdtype exported allows other modules to import and reuse it. This is consistent with other rule files in the codebase where message IDs are also exported.
7-7: Correct conversion to ESM exportChanged from CommonJS
export =to ESMexport defaultwhich properly aligns with the migration to ECMAScript modules.src/config/typescript.ts (2)
1-1: ESM path update looks goodThe import path now includes the
.jsextension which is required for ESM modules. This ensures proper module resolution in an ESM environment.
22-22: Correct conversion to ESM exportChanged from CommonJS
export =to ESMexport defaultwhich properly aligns with the migration to ECMAScript modules. The configuration object remains unchanged.src/rules/no-default-export.ts (2)
1-1: Consolidated imports with proper ESM pathThe import statement now consolidates multiple imports into a single line and includes the
.jsextension which is required for ESM modules. This improves readability while ensuring proper module resolution.
3-3: Correct conversion to ESM exportChanged from CommonJS
export =to ESMexport defaultwhich properly aligns with the migration to ECMAScript modules.src/utils/create-rule.ts (2)
3-3: ESM path update looks goodThe import path now includes the
.jsextension which is required for ESM modules. This ensures proper module resolution in an ESM environment.
5-5: Good change from type alias to exported interfaceConverting
ImportXPluginDocsfrom a type alias to an exported interface enhances its visibility and reusability across the codebase. Interfaces in TypeScript also provide better extensibility as they can be implemented and extended.src/rules/no-amd.ts (3)
5-5: Import path updated for ESM compatibilityThe import path for
createRulenow includes the.jsextension, which is required for ESM imports. This change is consistent with the migration to ESM as the primary module system.
7-7: Type export added for MessageIdThe
MessageIdtype is now properly exported, making it accessible to other modules. This is part of the migration to ESM and follows the pattern used in other rule files.
9-9: Export syntax changed from CommonJS to ESMThe export statement has been updated from
export =(CommonJS) toexport default(ESM). This change is essential for ESM compatibility and aligns with the PR's objective of migrating to ESM as the primary module system.test/rules/no-named-as-default.spec.ts (2)
1-1: Added CommonJS compatibility for testsImporting
cjsRequirefrom@pkgr/coreand aliasing it asrequireensures CommonJS-style imports can still be used in tests while the codebase transitions to ESM. This approach allows for backward compatibility with existing test infrastructure.
10-11: Updated import paths with .js extensionImport paths now include the
.jsextension, which is necessary for ESM compatibility. This change ensures proper module resolution in an ESM environment.src/rules/no-relative-packages.ts (2)
5-5: Import paths updated for ESM compatibilityAll import paths now include the
.jsextension, which is required for ESM imports. This ensures that module resolution works correctly in an ESM environment.Also applies to: 13-14
77-77: Export syntax changed from CommonJS to ESMThe export statement has been updated from
export =(CommonJS) toexport default(ESM). This change is consistent with the PR's objective of migrating to ESM as the primary module system.test/rules/no-named-default.spec.ts (2)
1-1: Added CommonJS compatibility for testsImporting
cjsRequirefrom@pkgr/coreand aliasing it asrequireensures that the tests can continue to use CommonJS-style imports while the codebase transitions to ESM. This approach maintains compatibility with the test infrastructure and parsers.
9-10: Updated import paths with .js extensionImport paths now include the
.jsextension, which is necessary for ESM compatibility. This change ensures proper module resolution in an ESM environment.src/rules/no-empty-named-blocks.ts (2)
3-3: Import path updated for ESM compatibilityThe import path has been updated to include the
.jsextension, which is required for proper ESM module resolution.
24-24: Export syntax updated for ESM compatibilityThe export syntax has been changed from CommonJS (
export =) to ESM (export default), which is a necessary change as part of migrating to ECMAScript Modules.src/rules/exports-last.ts (2)
3-3: Import path updated for ESM compatibilityThe import path has been updated to include the
.jsextension, which is required for proper ESM module resolution.
24-24: Export syntax updated for ESM compatibilityThe export syntax has been changed from CommonJS (
export =) to ESM (export default), which is a necessary change as part of migrating to ECMAScript Modules.test/rules/export.spec.ts (3)
1-1: Added utility for CommonJS require usage in ESMAdded
cjsRequirefrom@pkgr/coreto handle CommonJS module loading within an ESM environment, which is necessary because directrequire()calls aren't supported in ESM.
9-10: Import paths updated for ESM compatibilityImport paths have been updated to include the
.jsextension, which is required for proper ESM module resolution.
22-22: Replaced direct require calls with cjsRequire utilityReplaced direct calls to
require()with the importedcjsRequirefunction from@pkgr/core, which allows CommonJS module loading to work properly in an ESM environment.Also applies to: 134-135, 174-175
src/utils/module-cache.ts (2)
3-3: Import path updated for ESM compatibilityThe import path has been updated to include the
.jsextension, which is required for proper ESM module resolution.
9-9: Changed type declaration from type alias to interfaceThe
CacheObjecttype has been converted from a type alias to an interface. This change may offer more flexibility as interfaces can be extended and implemented by classes, whereas type aliases cannot be re-opened to add new properties.src/rules/no-named-default.ts (2)
1-1: Import path updated to use explicit file extensionThe import path has been updated to include the
.jsextension, which is required for proper ESM module resolution.
5-5: Export style changed to ESM default exportThe export syntax has been changed from CommonJS-style
export =to ESM-styleexport default, which aligns with the PR objective of migrating to ECMAScript Modules as the primary module system.src/rules/no-deprecated.ts (2)
4-10: Import paths updated with explicit file extensionsThe import statements have been updated to include the
.jsextension, which is necessary for ESM module resolution. Both the type import and regular imports have been consistently updated.
31-31: Export style changed to ESM default exportThe export syntax has been changed from CommonJS-style
export =to ESM-styleexport default, which is consistent with the migration to ECMAScript Modules.test/utils.ts (4)
3-3: Added CommonJS compatibility layerThe addition of
cjsRequirefrom@pkgr/corehelps maintain compatibility with CommonJS modules while migrating to ESM. This is important for test utilities that still need to access CommonJS modules or userequirefunctionality.
10-10: Updated semver import to namespace importChanged from default import to namespace import, which is more appropriate for ESM modules where the default export might not be guaranteed.
31-32: Improved type safety for require callAdded a generic type parameter to
requireto ensure type safety when accessing theversionproperty from the imported package.json. This helps catch potential type errors at compile time.
234-236: Extracted environment check to a constantExtracted the environment variable check to a separate constant for better readability and to avoid repetition. This is a good refactoring that makes the code more maintainable.
src/rules/no-webpack-loader-syntax.ts (2)
1-1: Import path updated with explicit file extensionThe import path has been updated to include the
.jsextension, which is required for ESM module resolution.
3-3: Export style changed to ESM default exportThe export syntax has been changed from CommonJS-style
export =to ESM-styleexport default, consistent with the migration to ECMAScript Modules.test/rules/no-useless-path-segments.spec.ts (2)
1-1: Adding CommonJS compatibility layer for ESM migrationThis import brings in the CommonJS-compatible require function, allowing the test to continue using
require()calls despite the codebase moving to ESM. This is an important compatibility layer during the migration process.
4-4: Updated import path with .js extensionAdding the
.jsextension is necessary for ESM module resolution. In ESM, file extensions are mandatory in relative imports, unlike CommonJS where they can be omitted.test/rules/no-named-as-default-member.spec.ts (2)
1-1: Adding CommonJS compatibility layer for ESM migrationThis import brings in the CommonJS-compatible require function, allowing the test to continue using
require()calls despite the codebase moving to ESM.
6-11: Updated import paths with .js extensionsAdding the
.jsextension to both regular imports and type imports is necessary for ESM module resolution. In ESM, file extensions are mandatory in relative imports, unlike CommonJS where they can be omitted.src/rules/max-dependencies.ts (4)
3-3: Updated import path with .js extensionAdding the
.jsextension is necessary for ESM module resolution. In ESM, file extensions are mandatory in relative imports, unlike CommonJS where they can be omitted.
5-8: Converted Options type to exported interfaceConverting from a local
typeto an exportedinterfaceimproves reusability and aligns with the pattern used in other rule files. This change is consistent with similar changes in other rules likeno-dynamic-require.tsandprefer-default-export.ts.
10-10: Exported MessageId typeMaking the MessageId type exported enhances its visibility and reusability from outside the module. This change is consistent with similar changes in other rule files like
no-amd.tsandno-named-as-default.ts.
12-12: Changed export style from CommonJS to ESMSwitching from
export =(CommonJS) toexport default(ESM) is a key part of the migration to ESM as the primary module system. This change aligns with the main objective of the PR.test/rules/no-unresolved.spec.ts (2)
13-14: Updated import paths with .js extensionsAdding the
.jsextension to both regular imports and type imports is necessary for ESM module resolution. In ESM, file extensions are mandatory in relative imports, unlike CommonJS where they can be omitted.
19-20: Created CommonJS-compatible require functionThis creates a CommonJS-compatible
requirefunction using Node.js built-increateRequireAPI. This allows the test file to userequire()statements despite running in an ESM context. The blank line after the declaration also helps visually separate this setup code from the rest of the file.test/rules/no-dynamic-require.spec.ts (5)
1-1: LGTM: Added import forcjsRequirefunctionThe import is necessary for the migration to ESM as it provides a way to handle CommonJS require calls in an ESM environment.
3-3: LGTM: Added type import for TSESLintGood addition of the type import to ensure type safety when using the cjsRequire function.
5-5: LGTM: Updated import path with .js extensionThe explicit .js extension is required for ESM imports, unlike CommonJS where extensions are optional.
35-35: LGTM: Replaced require with cjsRequireThe replacement of the CommonJS require with cjsRequire includes proper type annotation, enhancing type safety while maintaining functionality.
167-167: LGTM: Replaced require with cjsRequireConsistent with the previous replacement, using cjsRequire with proper type annotation.
test/rules/no-duplicates.spec.ts (2)
3-3: LGTM: Imported cjsRequire aliased as requireSmart approach to alias cjsRequire as require, which minimizes changes throughout the file while adapting to ESM.
12-13: LGTM: Updated import paths with .js extensionsProper addition of .js extensions to imports, which is required for ESM compatibility.
test/rules/no-anonymous-default-export.spec.ts (3)
1-1: LGTM: Added import for cjsRequire functionNecessary import for ESM migration to replace CommonJS require functionality.
9-10: LGTM: Updated import paths with .js extensionsProper addition of .js extensions for ESM compatibility.
75-75: LGTM: Replaced require with cjsRequireConsistent replacement of CommonJS require with the ESM-compatible cjsRequire function.
src/rules/no-self-import.ts (3)
7-8: LGTM: Updated import paths with .js extensionsProperly updated import paths to include .js extensions for ESM compatibility. The change to '../utils/index.js' ensures explicit module resolution.
10-10: LGTM: Exported MessageId typeExporting the MessageId type is consistent with the pattern used across other rule files in the codebase.
28-28: LGTM: Updated to ESM export syntaxCorrectly changed from CommonJS
export =to ESMexport defaultsyntax, which is essential for the migration to ESM as the primary module system.test/package.spec.ts (5)
3-3: Good addition of the node URL module for ES module compliance.This import of
pathToFileURLis necessary for properly handling file URLs in ES modules, particularly for the dynamic import on line 28.
7-7: Appropriate update to import paths with.jsextension.Adding the
.jsextension to imports is a necessary change for ESM compatibility. This follows the ESM requirement that relative imports must include file extensions.Also applies to: 9-9
23-25: Good change fromconsttoletfor module variable.Switching from
consttoletis appropriate since the variable is now being assigned in thebeforeAllhook rather than at declaration time.
51-61: Great conversion to async test with dynamic import.Converting the test to be async and using dynamic imports with
pathToFileURLis the appropriate approach for ES modules. This test properly verifies that rule configurations exist.
27-29:❓ Verification inconclusive
Good implementation of async module loading.
Using
beforeAllwith an async function to dynamically import the module is the correct approach for ES modules. The use ofpathToFileURLensures proper URL formatting for the import.However, I noticed a potential issue related to the pipeline failure.
🏁 Script executed:
#!/bin/bash # Check if there are any imports of FileEnumerator from eslint/use-at-your-own-risk rg "FileEnumerator.*eslint/use-at-your-own-risk" --type tsLength of output: 152
Attention: Async Module Loading Verified & Potential Pipeline Issue Detected
The dynamic import implementation in the test file (
test/package.spec.ts, lines 27-29) is correctly implemented. However, the pipeline failure might be related to the import found in another part of the codebase:
- File:
src/rules/no-unused-modules.ts
Location:import { FileEnumerator } from 'eslint/use-at-your-own-risk'Please verify if this import is intentional and review its impact on the pipeline, as it could be contributing to unstable builds.
🧰 Tools
🪛 GitHub Actions: CI
[error] 28-28: SyntaxError: The requested module 'eslint/use-at-your-own-risk' does not provide an export named 'FileEnumerator'
src/rules/no-dynamic-require.ts (4)
3-3: Appropriate update to import path with.jsextension.Adding the
.jsextension to the import path is necessary for ESM compatibility. This follows the ESM requirement that relative imports must include file extensions.
33-35: Good conversion from type alias to exported interface.Converting the
Optionsfrom a type alias to an exported interface is a good practice, as it:
- Makes the type available for external consumption
- Provides better extensibility through interface inheritance
- Maintains consistent pattern with other rule option definitions in the codebase
This change aligns with the pattern used in other rules like
no-nodejs-modules.ts,no-unassigned-import.ts, etc.
37-37: Appropriate export of the MessageId type.Exporting the
MessageIdtype is consistent with the pattern used throughout the codebase, making the type available for external consumers.
39-39: Good conversion from CommonJS to ES module export.Changing from
export =(CommonJS) toexport default(ES modules) is appropriate for the migration to ES modules as the primary module system. This ensures compatibility with ESM consumers.test/rules/namespace.spec.ts (2)
1-1: Good addition of CommonJS require compatibility.Using
cjsRequirefrom@pkgr/coreand aliasing it asrequireis a smart approach to maintain compatibility with the existing tests that userequire()while migrating to ES modules. This ensures the test will continue to work without having to rewrite all the require calls.
11-12: Appropriate update to import paths with.jsextension.Adding the
.jsextension to imports is necessary for ESM compatibility. This follows the ESM requirement that relative imports must include file extensions.src/utils/import-type.ts (1)
4-4: Appropriate update to import paths with.jsextension.Adding the
.jsextension to imports is necessary for ESM compatibility. This follows the ESM requirement that relative imports must include file extensions.Also applies to: 6-7
test/rules/first.spec.ts (3)
3-3: Good addition ofcjsRequirefrom @pkgr/coreThe addition of
cjsRequireis a good approach for handling CommonJS module loading in an ESM environment, which is essential for this migration.
6-6: Correctly updated import path with .js extensionAdding the
.jsextension to the import path is necessary for ESM compatibility. This change correctly follows ESM module resolution rules.
34-34: Properly replaced require with cjsRequireUsing
cjsRequireinstead of the nativerequirefunction is the correct approach for loading CommonJS modules in an ESM context.test/rules/no-cycle.spec.ts (2)
1-1: Good approach importing cjsRequire as requireAliasing
cjsRequireasrequireminimizes changes throughout the file, making the migration more maintainable by preserving the existing function calls.
5-6: Correctly updated import paths with .js extensionsThese changes properly include the
.jsextension required for ESM imports and maintain the type imports needed for TypeScript.test/rules/no-default-export.spec.ts (2)
1-1: Good approach importing cjsRequire as requireAliasing
cjsRequireasrequireallows the existing code to function in an ESM context without extensive modifications.
6-7: Correctly updated import paths with .js extensionsAdding the
.jsextension to the import paths is necessary for ESM compatibility and properly maintains the type imports.src/index.ts (2)
3-74: Well-executed update of all import paths with .js extensionsAll import paths have been consistently updated to include the
.jsextension required for ESM compatibility. This thorough approach ensures the module will work correctly in ESM environments.
181-195: Good implementation of dual export pattern for maximum compatibilityThe implementation of both default export and named exports is an excellent approach that:
- Provides flexibility for module consumers to import in their preferred style
- Makes migration easier for existing users
- Follows modern JavaScript best practices
// Consumers can use either style: import plugin from 'eslint-plugin-import-x' // OR import { rules, configs } from 'eslint-plugin-import-x'This dual-export pattern is ideal for library migrations to ESM.
test/node-resolver.spec.ts (5)
1-3: Good addition of ESM compatible importsAdding
createRequireandfileURLToPathimports is necessary for ESM compatibility since the codebase is migrating to ES modules as primary.
9-12: Properly handling ESM file path resolutionGood implementation of CommonJS compatibility in an ESM context. In ESM environments, globals like
__dirnameand__filenameare not available, so this correctly creates compatible alternatives.
18-18: Correct update to use ESM-compatible dirnameThe change from
__dirnameto_dirnameis necessary for ES modules compatibility.
29-29: Correct update to use ESM-compatible filenameThe change from
__filenameto_filenameis necessary for ES modules compatibility.
57-57: Updated test case to reflect Babel config file extension changeThe test was correctly updated to expect
babel.config.cjsinstead ofbabel.config.js, which aligns with the CommonJS file extension convention in an ESM project.src/rules/no-unresolved.ts (3)
5-5: Correctly updated import paths with .js extensionAdding the
.jsextension to import paths is required for ES modules compatibility. This change ensures proper module resolution in an ESM environment.Also applies to: 14-14
16-19: Improved type exports for better module consumptionChanging from local type definitions to exported types (
export type Optionsandexport type MessageId) enhances TypeScript type inference when other modules import from this file.Also applies to: 21-21
23-23: Updated export syntax to ESM standardChanging from CommonJS-style
export =to ES modules-styleexport defaultis a necessary part of the migration to ES modules. This ensures compatibility with ESM import statements.src/utils/resolve.ts (3)
3-3: Correctly updated imports for ESM compatibilityAdding
fileURLToPathimport and updating relative import paths with.jsextensions ensures proper module resolution in an ESM environment.Also applies to: 13-13, 18-19
29-30: Correct usage of ESM-compatible dirname and filenameUpdated path resolution to use the new
_dirnameand_filenamevariables correctly, maintaining the same functionality across both module systems.
21-25:❓ Verification inconclusive
Well-implemented fallback for ESM environment
The code intelligently handles both CommonJS and ESM environments by checking if
__filenameis defined, and falling back tofileURLToPath(import.meta.url)if it's not. This ensures compatibility across different module systems.The pipeline shows a warning about
import.metanot being available in ES2015. Consider updating the TypeScript target environment or adding appropriate polyfills:
🏁 Script executed:
#!/bin/bash # Check the current TypeScript target configuration grep -r "target" --include="tsconfig*.json" .Length of output: 5164
Attention: Verify TS Target for
import.metaCompatibilityThe fallback implementation in
src/utils/resolve.ts(lines 21–25) is solid and correctly supports both CommonJS and ESM environments. However, the pipeline warning aboutimport.metanot being available in ES2015 suggests that the TypeScript target in your project might be set too low.
- Action Item: Please verify your project's
tsconfig.jsonconfiguration. If it targets ES2015, consider upgrading it to a later version (e.g. ES2020 or ESNext) or add the necessary polyfills to supportimport.meta.url.🧰 Tools
🪛 GitHub Actions: CI
[warning] 23-23: "import.meta" is not available in the configured target environment ("es2015") and will be empty
src/rules/no-namespace.ts (3)
8-8: Correctly updated import path with .js extensionAdding the
.jsextension to the import path is required for ES modules compatibility. This change ensures proper module resolution in an ESM environment.
10-14: Improved type exports for better module consumptionChanging from local type definitions to exported types (
export type MessageIdandexport interface Options) enhances TypeScript type inference when other modules import from this file. Good choice to use interface for Options since it's an object type.
16-16: Updated export syntax to ESM standardChanging from CommonJS-style
export =to ES modules-styleexport defaultis a necessary part of the migration to ES modules. This ensures compatibility with ESM import statements.src/rules/first.ts (3)
3-4: Well-structured imports for ESM compatibility.The updated import paths now include
.jsfile extensions, which is required for proper module resolution in ESM. This change is necessary and aligns with the PR objective of migrating to ESM as the primary module system.
23-23: Good practice: Exporting type declarations.Changing these type declarations to exported types improves your module interface by making them available to consumers. This enhances type safety and allows external code to reference these types directly.
Also applies to: 25-25
27-27: Correct export syntax for ESM.Changing from CommonJS-style
export =to ESM-styleexport defaultis appropriate for the migration to ECMAScript modules and follows modern JavaScript standards.src/rules/no-named-as-default.ts (3)
3-3: Proper ESM import path.Adding the
.jsfile extension to the import path is required for ESM compatibility and is consistent with the changes made across the codebase.
5-5: Type visibility improved.Exporting the
MessageIdtype enhances the module's public API and follows the pattern seen in other rule files as well, creating consistency across the codebase.
7-7: Default export for ESM compatibility.Converting from CommonJS export syntax to ESM default export syntax aligns with the project's goal of transitioning to ECMAScript modules.
test/rules/newline-after-import.spec.ts (2)
1-1: Clever approach for handling require in ESM context.Using
cjsRequirefrom@pkgr/coreand aliasing it asrequireallows tests to maintain CommonJS functionality while operating in an ESM environment. This is a smart transition strategy.
5-6: Updated import paths for ESM compatibility.Adding
.jsextensions to import paths ensures proper module resolution in the ESM environment, matching the changes made throughout the codebase.src/rules/named.ts (3)
5-6: ESM-compatible import paths.Adding
.jsextensions to import paths is consistent with ESM requirements and follows the pattern established throughout the codebase during this migration.
8-8: Enhanced type visibility.Exporting the
MessageIdtype improves the module's public interface and follows modern TypeScript best practices for type declarations.
10-10: Migrated to ESM export syntax.Converting from CommonJS
export =to ESMexport defaultensures compatibility with the new module system being adopted.src/node-resolver.ts (2)
7-7: Valid update to import pathThe addition of ".js" extension in the import path is necessary for ESM modules, which require explicit file extensions.
9-31: Improved type structure with interfaceConverting from a type alias to an interface that extends ResolveOptions improves code clarity and maintainability.
This change from:
export type NodeResolverOptions = { ... } & ResolveOptionsto:
export interface NodeResolverOptions extends ResolveOptions { ... }maintains the same functionality while using a more explicit and structured approach.
tsconfig.base.json (2)
5-5: Added root directory specificationAdding rootDir property helps TypeScript better understand the source code structure.
7-10: Improved module resolution pathsThe updated path mappings provide more specific file references, which enhances TypeScript's ability to locate and resolve modules.
The changes make the import paths more precise by:
- Specifying the exact entry point file for the main package import
- Restricting wildcard imports to TypeScript files only
src/rules/newline-after-import.ts (4)
8-8: Valid update to import pathAdding the ".js" extension to the import path is required for ESM modules compatibility.
77-81: Improved type definition with exported interfaceConverting from a type alias to an exported interface improves code organization and allows for explicit importing of types.
83-83: Exported MessageId typeExporting the MessageId type allows it to be imported by other modules if needed.
85-85: Changed export syntax for ESM compatibilitySwitching from CommonJS
export =to ESMexport defaultis necessary for ESM module compatibility.src/rules/no-anonymous-default-export.ts (3)
7-7: Valid update to import pathAdding the ".js" extension to the import path is required for ESM modules compatibility.
113-122: Improved type definition with exported interfaceConverting from a type alias to an exported interface enhances code organization and allows for explicit importing of this type.
131-131: Changed export syntax for ESM compatibilitySwitching from CommonJS
export =to ESMexport defaultis necessary for ESM module compatibility.test/rules/no-mutable-exports.spec.ts (2)
1-1: Import adjustment for CommonJS compatibility in ESM contextThe change to import
cjsRequire as requirefrom@pkgr/corehelps maintain CommonJS functionality within an ESM environment. This is a necessary adaptation for the ESM migration.
5-6: Added .js extension to import pathsAdding file extensions to import paths is necessary when migrating to ESM, as ESM requires explicit file extensions for relative imports. This ensures proper module resolution in the new module system.
src/rules/no-useless-path-segments.ts (4)
7-13: Updated import paths with .js extensionThe import paths have been updated to include the
.jsextension, which is required for ESM module resolution. Also, imports now point toindex.jsexplicitly, making the module resolution more predictable.
42-44: Made Options type an exported interfaceConverting from a local type to an exported interface improves reusability and allows other modules to reference this type directly. This enhances the type system's visibility across the codebase.
46-46: Exported MessageId typeMaking the MessageId type exported increases its visibility and reusability across the codebase, which aligns with TypeScript best practices for public API types.
48-48: Changed export style from CommonJS to ESMSwitching from
export =(CommonJS style) toexport default(ESM style) aligns with the migration to ESM as the primary module system. This is a necessary change for ESM compatibility.src/rules/no-nodejs-modules.ts (4)
1-1: Updated import path with .js extensionThe import path has been updated to include the
.jsextension and point toindex.jsexplicitly, which is required for ESM module resolution.
3-5: Made Options type an exported interfaceConverting from a local type to an exported interface improves reusability and allows other modules to reference this type directly. This change follows the same pattern applied across the codebase during this migration.
7-7: Exported MessageId typeThe MessageId type is now exported, increasing its visibility and reusability across the codebase, consistent with the changes in other rule modules.
9-9: Changed export style from CommonJS to ESMSwitching from
export =(CommonJS style) toexport default(ESM style) aligns with the migration to ESM as the primary module system. This is consistent with the changes in other rule modules.test/utils/resolve.spec.ts (6)
2-8: Updated imports for ESM compatibilityAdded
createRequirefrom Node.js modules and updated imports from Jest packages to ensure the test utilities work properly in an ESM environment. The additional type import forCjsRequirehelps maintain type safety.
10-10: Added .js extension to utility import pathUpdated the import path to include the
.jsextension, which is required for ESM module resolution.
12-13: Updated plugin imports to support ESMUpdated the imports from the plugin itself to properly work in an ESM context, including adding a type import for
NewResolver.
20-20: Created local require function for ESM compatibilityIn ESM, the global
requirefunction is not available. Creating a localrequirefunction usingcreateRequireis a common pattern when migrating to ESM while still needing to import CommonJS modules.
115-117: Added type assertion for imported resolverAdded a type assertion to ensure that the imported resolver has the correct structure. This improves type safety and makes the code more robust.
329-331: Added type assertion for imported resolverAdded a type assertion to ensure that the imported resolver has the correct structure, consistent with the earlier instance of this pattern.
src/rules/prefer-default-export.ts (3)
3-3: Update import path to include .js extensionThis change is part of the migration to ESM, which requires explicit file extensions in import paths. The
.jsextension is now included in the import path.
5-7: Changed type alias to exported interfaceConverting from a type alias to an exported interface improves public API visibility and is more consistent with other exported option interfaces in the codebase.
11-11: Changed CommonJS export to ESM default exportConverting from
export =(CommonJS) toexport default(ESM) syntax is a necessary part of migrating to ESM. This aligns with the PR objective of making ESM the primary module system.test/rules/no-extraneous-dependencies.spec.ts (11)
2-4: Added required imports for ESM compatibilityThe addition of
createRequireandfileURLToPathis necessary for ESM compatibility. These functions allow for dynamic module loading and proper path resolution in an ESM environment.
6-6: Added CjsRequire type import for type safetyImporting the
CjsRequiretype from@pkgr/coreensures proper typing for the dynamically created require function.
9-9: Updated import path to include .js extensionIncluding the
.jsextension in the import path is required in ESM modules for local files.
14-15: Created typed require functionCreating a properly typed require function using
createRequireis necessary in ESM where the globalrequirefunction is not available.
16-17: Added dirname calculation for ESM environmentIn ESM modules,
__dirnameis not available. This code properly calculates the directory path usingfileURLToPath(import.meta.url).
18-22: Updated package.json loading with typed requireUsing the typed require function to load package.json ensures the dependencies are correctly typed as records of strings, improving type safety.
91-91: Updated dirname referenceReplaced
__dirnamewith_dirnameto ensure path resolution works correctly in ESM environment.
113-113: Updated dirname referenceReplaced
__dirnamewith_dirnameto ensure path resolution works correctly in ESM environment.
342-342: Updated dirname referenceReplaced
__dirnamewith_dirnameto ensure path resolution works correctly in ESM environment.
349-349: Updated dirname referenceReplaced
__dirnamewith_dirnameto ensure path resolution works correctly in ESM environment.
440-440: Updated dirname referenceReplaced
__dirnamewith_dirnameto ensure path resolution works correctly in ESM environment.src/rules/export.ts (4)
9-9: Updated import path to include .js extensionIncluding the
.jsextension in the import path is required in ESM modules for local files.
111-111: Exported MessageId typeExporting the
MessageIdtype makes it available for external use, improving the public API of the module and following the pattern established in other rule modules.
113-113: Changed CommonJS export to ESM default exportConverting from
export =(CommonJS) toexport default(ESM) syntax is a necessary part of migrating to ESM. This aligns with the PR objective of making ESM the primary module system.
248-248:❓ Verification inconclusive
Changed forEach to $forEach method
The method name change from
forEachto$forEachsuggests an update in theExportMapclass implementation. Ensure that the$forEachmethod behaves the same as the previousforEachmethod.
🏁 Script executed:
#!/bin/bash # Description: Check the implementation of the ExportMap.$forEach method # Look for the ExportMap class definition and its forEach//$forEach method rg -A 10 "class ExportMap" --type typescript rg -A 5 "\$forEach" --type typescriptLength of output: 155
I'm generating an updated shell script to re-verify the implementation of the
ExportMap.$forEachmethod using a file filter for TypeScript files. Please run the script below and review its output to confirm that the new$forEachmethod in yourExportMapclass behaves as intended in place of the oldforEachmethod.Once you confirm that the output correctly shows the new implementation in the correct locations, you can proceed with the review changes accordingly.
🏁 Script executed:
#!/bin/bash # Description: Re-check for ExportMap class and its $forEach method implementation in TypeScript files. rg -A 10 "class ExportMap" -g "*.ts" rg -A 5 "\$forEach" -g "*.ts"Length of output: 778
Confirm the
$forEachBehavior in ExportMap
The automated search shows that while the call to$forEachinsrc/rules/export.tsis present, there’s no explicit definition of a$forEachmethod in theExportMapclass (as visible, for example, insrc/utils/export-map.ts). Please verify manually whether this change represents an alias, refactoring, or a re-implementation that mirrors the behavior of the previousforEachmethod. Ensure that the new$forEachinvocation onremoteExportsfunctions identically to the old one across all usage contexts.test/rules/default.spec.ts (5)
2-2: Added fileURLToPath import for ESM compatibilityThe
fileURLToPathfunction is necessary for proper path handling in an ESM environment.
4-4: Added cjsRequire import for CommonJS compatibilityUsing
cjsRequirefrom@pkgr/coreallows for proper handling of CommonJS-style requires in an ESM environment.
11-12: Updated import paths to include .js extensionIncluding the
.jsextension in import paths is required in ESM modules for local files.
21-25: Added dirname calculation for ESM environmentThis code properly handles directory path calculation in both CommonJS and ESM environments:
- In ESM, it uses
fileURLToPath(import.meta.url)to get the file path and then extracts the directory.- In CommonJS, it falls back to the standard
__dirnamevariable.This ensures compatibility across both module systems during the transition.
298-299: Updated dirname referencesAll instances of
__dirnamehave been replaced with_dirnameto ensure path resolution works correctly in ESM environment.Also applies to: 315-316, 331-332, 347-348, 422-423
test/rules/named.spec.ts (7)
2-2: Added fileURLToPath for ESM compatibility.The import of
fileURLToPathfrom 'node:url' is needed to create a polyfill for__dirnamewhich doesn't exist in ESM environments.
4-4: Added cjsRequire for CommonJS module compatibility.Using
cjsRequirefrom@pkgr/coreallows the code to maintain compatibility with CommonJS-style requires while migrating to ESM.
14-15: Updated import paths with .js extension.Adding the
.jsextension to import paths is required for ESM module resolution since automatic extension resolution isn't supported in ESM.
20-23: Added __dirname polyfill for ESM compatibility.Created a fallback mechanism for
__dirnamewhich doesn't exist in ESM. The code checks if__dirnameis undefined (ESM environment) and usesfileURLToPath(import.meta.url)instead, maintaining compatibility with both module systems.
495-496: Updated directory resolution to use _dirname polyfill.Using the new
_dirnamepolyfill instead of directly referencing__dirnameensures compatibility with ESM.
520-521: Updated directory resolution to use _dirname polyfill.Using the new
_dirnamepolyfill instead of directly referencing__dirnameensures compatibility with ESM.
536-537: Updated directory resolution to use _dirname polyfill.Using the new
_dirnamepolyfill instead of directly referencing__dirnameensures compatibility with ESM.test/rules/no-absolute-path.spec.ts (2)
1-1: Added cjsRequire for CommonJS module compatibility.Using
cjsRequirefrom@pkgr/coreallows the code to maintain compatibility with CommonJS-style requires while migrating to ESM.
5-6: Updated import paths with .js extension.Adding the
.jsextension to import paths is required for ESM module resolution since automatic extension resolution isn't supported in ESM.src/rules/no-unused-modules.ts (4)
12-12: Updated import path with .js extension.Adding the
.jsextension to the import path is required for ESM module resolution.
22-22: Updated import path with .js extension and changed path structure.The import path now includes both the
.jsextension and uses/index.jsexplicitly, which is required for proper ESM module resolution.
392-398: Converted type alias to exported interface.Changed from a type alias to an exported interface, which enhances visibility and extensibility. This is consistent with modern TypeScript practices and the changes made to other option types in the codebase.
402-402: Updated export syntax for ESM compatibility.Changed from CommonJS-style
export =to ESM'sexport default, which is required for ESM modules.src/rules/no-unassigned-import.ts (3)
5-5: Updated import path with .js extension and changed path structure.The import path now includes both the
.jsextension and uses/index.jsexplicitly, which is required for proper ESM module resolution.
29-31: Converted type alias to exported interface.Changed from a type alias to an exported interface, which enhances visibility and extensibility. This is consistent with modern TypeScript practices and the changes made to other option types in the codebase.
35-35: Updated export syntax for ESM compatibility.Changed from CommonJS-style
export =to ESM'sexport default, which is required for ESM modules.src/rules/no-import-module-exports.ts (6)
3-3: Added appropriate CommonJS require replacement.The addition of
cjsRequirefrom '@pkgr/core' is a good approach for maintaining CommonJS compatibility while transitioning to ESM.
7-8: Updated import paths with proper file extensions.Adding '.js' extensions to import paths is required for ESM compatibility. This change ensures correct module resolution in the ESM context.
15-15: Replaced require.resolve with cjsRequire.resolve.Correctly replaced Node.js built-in
require.resolvewithcjsRequire.resolvefrom the '@pkgr/core' package to maintain compatibility with ESM.
45-47: Changed type declaration to exported interface.Properly changed the
Optionstype from a local type to an exported interface, making it available for import in other modules. This improves code organization and reusability.
49-49: Changed type declaration to exported type.Properly changed the
MessageIdtype from a local type to an exported type, improving visibility and accessibility across modules.
51-51:✅ Verification successful
Updated export statement to use default export.
Changed from CommonJS-style export (
export =) to ESM-style default export (export default), which is necessary for ESM compatibility.Let's verify that imports of this rule have been updated across the codebase:
🏁 Script executed:
#!/bin/bash # Search for import statements related to this rule rg -A 1 $'(import|require).*no-import-module-exports'Length of output: 1245
Verified ESM export usage for rule "no-import-module-exports" across the codebase.
The change from CommonJS-style export (
export =) to ESM-style default export (export default) is correctly applied (seesrc/rules/no-import-module-exports.ts, line 51). Additionally, the grep results confirm that all import statements (e.g., insrc/index.tsandtest/rules/no-import-module-exports.spec.ts) have been updated to use ESM import syntax.src/rules/dynamic-import-chunkname.ts (4)
6-6: Updated import path with proper file extension.Adding '.js' extension to the import path is required for ESM compatibility. This change ensures correct module resolution in the ESM context.
8-12: Changed type declaration to exported interface.Properly changed the
Optionstype from a local type to an exported interface, making it available for import in other modules. This improves code organization and reusability.
14-23: Changed type declaration to exported type.Properly changed the
MessageIdtype from a local type to an exported type, improving visibility and accessibility across modules.
24-24:✅ Verification successful
Updated export statement to use default export.
Changed from CommonJS-style export (
export =) to ESM-style default export (export default), which is necessary for ESM compatibility.Let's verify that imports of this rule have been updated across the codebase:
🏁 Script executed:
#!/bin/bash # Search for import statements related to this rule rg -A 1 $'(import|require).*dynamic-import-chunkname'Length of output: 901
Export Statement Update Verified:
The change insrc/rules/dynamic-import-chunkname.tsto useexport defaulthas been successfully implemented. The verification confirms that all usages across the codebase—from tests (test/rules/dynamic-import-chunkname.spec.ts) to the main index (src/index.ts) and documentation—are correctly importing the rule using ESM-style default imports.src/rules/consistent-type-specifier-style.ts (3)
3-3: Updated import path with proper file extension.Adding '.js' extension to the import path is required for ESM compatibility. This change ensures correct module resolution in the ESM context.
47-47: Changed type declaration to exported type.Properly changed the
Optionstype from a local type to an exported type, improving visibility and accessibility across modules.
51-51:✅ Verification successful
Updated export statement to use default export.
Changed from CommonJS-style export (
export =) to ESM-style default export (export default), which is necessary for ESM compatibility.Let's verify that imports of this rule have been updated across the codebase:
🏁 Script executed:
#!/bin/bash # Search for import statements related to this rule rg -A 1 $'(import|require).*consistent-type-specifier-style'Length of output: 662
ESM Import Updates Verified – Default Export Change is Consistent
The shell script output confirms that all references to the
consistent-type-specifier-stylerule now use ESM default imports. Specifically:
- In src/index.ts, the rule is imported with a default import.
- In test/rules/consistent-type-specifier-style.spec.ts, the rule is imported as the default export.
- The ESLint config and documentation references are in line with these changes.
These findings verify that the export change from CommonJS
export =to ESM-styleexport defaulthas been fully adopted across the codebase.src/rules/no-absolute-path.ts (3)
8-9: Updated import paths with proper file extensions.Added '.js' extensions to import paths and separated type imports, which is required for ESM compatibility. This change ensures correct module resolution in the ESM context.
11-11: Changed type declaration to exported type.Properly changed the
MessageIdtype from a local type to an exported type, improving visibility and accessibility across modules.
13-13:✅ Verification successful
Updated export statement to use default export.
Changed from CommonJS-style export (
export =) to ESM-style default export (export default), which is necessary for ESM compatibility.Let's verify that imports of this rule have been updated across the codebase:
🏁 Script executed:
#!/bin/bash # Search for import statements related to this rule rg -A 1 $'(import|require).*no-absolute-path'Length of output: 575
Export Changed to ESM Default Export – Verified across the Codebase
The change from CommonJS-style export (
export =) to ESM-style default export (export default) insrc/rules/no-absolute-path.tshas been confirmed. Verification of import statements shows:
- src/index.ts: Uses
import noAbsolutePath from './rules/no-absolute-path.js'- Test File:
test/rules/no-absolute-path.spec.tsimports the rule as a default export.- Documentation:
docs/rules/no-absolute-path.mdreferences the rule correctly.All instances have been updated accordingly.
src/utils/export-map.ts (4)
7-7: Default import to namespace import change for doctrine is appropriate.Changing from default import to namespace import ensures all exports from doctrine are accessible under a single namespace, which is more explicit and less error-prone.
21-28: Correctly added.jsextensions to import paths.Adding
.jsextensions to import paths is required for ESM compatibility as ESM requires explicit file extensions, unlike CommonJS.
42-47: Type aliases converted to interfaces appropriately.Converting from type aliases to interfaces improves extensibility and is a good practice when modeling object shapes that might need to be extended in the future.
Also applies to: 49-52, 54-57
916-916: Updated method name reference is consistent.The call to
$forEachcorrectly uses the renamed method, maintaining consistency with the earlier change.test/cli.spec.ts (3)
6-6: Correctly added file URL handling for ESM compatibility.The addition of
fileURLToPathand usingimport.meta.urlto determine the test directory path is the correct approach for ESM modules, as they use URL-based module resolution.Also applies to: 13-13
🧰 Tools
🪛 GitHub Actions: CI
[error] SyntaxError: The requested module 'eslint/use-at-your-own-risk' does not provide an export named 'LegacyESLint'
18-20: Updated path handling is appropriate for ESM context.Using the
testDiras the CWD and updating the file paths to be relative to that directory makes the test more robust and compatible with ESM module resolution.Also applies to: 30-30
🧰 Tools
🪛 GitHub Actions: CI
[error] SyntaxError: The requested module 'eslint/use-at-your-own-risk' does not provide an export named 'LegacyESLint'
36-40: Path resolution updated correctly for the second test case.Similar to the first test case, the path handling has been appropriately updated to work with the new ESM-based structure.
Also applies to: 49-50
🧰 Tools
🪛 GitHub Actions: CI
[error] SyntaxError: The requested module 'eslint/use-at-your-own-risk' does not provide an export named 'LegacyESLint'
src/rules/no-restricted-paths.ts (5)
7-13: Import paths properly updated with.jsextensions.Adding
.jsextensions to import paths is required for ESM compatibility and follows the pattern seen in other files in this PR.
35-43: Type definition changed to an exported interface.Converting from a type alias to an exported interface improves discoverability and allows for extension in other files. This aligns with the type changes made in other files.
45-45: MessageId type is now exported.Making the MessageId type exported allows it to be used by other files, which improves modularity and type-safety across the codebase.
47-52: Validator interface is now exported.Converting Validator from a type alias to an exported interface follows the same pattern as other types in this file and across the codebase, improving consistency.
54-54: Export style updated to ESM format.Changing from
export =(CommonJS style) toexport default(ESM style) is appropriate for the migration to ESM as the primary module system.src/rules/group-exports.ts (4)
3-3: Updated import path with.jsextension.Adding the
.jsextension to the import path is required for ESM compatibility and matches the pattern in other files.
5-5: Literal type is now exported.Making the Literal type exported allows it to be used by other files, consistent with the type visibility changes in other files.
38-38: MessageId type is now exported.Making the MessageId type exported improves the type visibility across the codebase and aligns with similar changes in other files, such as in no-restricted-paths.ts.
40-40: Export style updated to ESM format.Changing from
export =toexport defaultconverts the CommonJS style export to ESM style, which is appropriate for the migration to ESM.test/rules/prefer-default-export.spec.ts (3)
4-4: Added TSESLint type import for better type safety.The addition of the TSESLint type import enhances type definitions available in the file, which will improve type checking and developer experience.
10-11: Updated import paths with .js extension for ESM compatibility.Adding the
.jsextension to import paths is necessary for ESM module resolution. This change aligns with the PR objective of migrating to ESM as the primary module system.
269-272: Improved type safety for parser configuration.Adding the type parameter
<TSESLint.Parser.LooseParserModule>to therequirefunction call enhances type safety by explicitly specifying the expected parser module type.src/rules/no-internal-modules.ts (4)
3-8: Restructured imports with .js extension for ESM compatibility.The import statement has been updated to a multi-line format with explicit
.jsextension, which is required for proper module resolution in ESM. This change supports the migration from CommonJS to ECMAScript modules.
36-39: Converted type to exported interface.Changed from a local type to an exported interface, making it accessible to other modules. This improves the modularity of the codebase and supports better type checking across modules.
41-41: Exported MessageId type for better module interoperability.Making the
MessageIdtype explicitly exported allows other modules to reference it, which improves type consistency across the codebase.
43-43: Changed from CommonJS to ESM default export.Replaced CommonJS-style
export =with ESMexport default, aligning with the PR's objective to migrate to ECMAScript Modules as the primary module system.test/utils/parse.spec.ts (9)
2-6: Added necessary imports for ESM compatibility.Added imports for
createRequire,jest,TSESLint, and__importDefaultto support the transition to ESM modules. ThecreateRequirefunction is particularly important for loading CommonJS modules in an ESM context.
8-11: Updated import paths and handling for ESM compatibility.Added
.jsextension to import paths and adjusted the import forparseStubParserto use__importDefault, which is necessary for handling CommonJS default exports in an ESM context.
21-22: Created a Node.js require function for the current module.Using
createRequire(import.meta.url)creates a require function scoped to the current module's URL, which is necessary for loading CommonJS modules in an ESM context.
55-55: Changed parser setup to use setter method.Changed from direct property assignment
parseStubParser.parse = parseSpyto using a setter methodparseStubParser.setParse(parseSpy). This approach is more encapsulated and follows better object-oriented practices.
69-71: Improved type safety for mock parser options.Added explicit type assertion for mock parser options to
TSESLint.ParserOptions, which enhances type safety and reduces the risk of type errors.
84-109: Refactored test to use async/await with dynamic imports.Refactored the test to use async/await with dynamic imports, which is necessary for ESM modules. The approach also includes module resets and checks to ensure that fresh instances of parse functions are used. This prevents test contamination and ensures isolation.
139-165: Refactored test for alternate parser in settings to use async/await.Similar to the previous test, this one has been refactored to use async/await with dynamic imports for ESM compatibility. The approach ensures test isolation by resetting modules and verifying that fresh instances are used.
313-347: Refactored test for parser preferences to use async/await.Refactored the test to use async/await with dynamic imports for ESM compatibility. This ensures proper module resolution and test isolation, which is particularly important when testing parser preferences.
351-351: Updated remaining instances to use setter method for parse spy.Consistently changed all instances of direct property assignment to use the setter method
setParse, maintaining code consistency throughout the file.Also applies to: 371-371
src/utils/legacy-resolver-settings.ts (4)
6-6: Added cjsRequire import for CommonJS compatibility.Added import for
cjsRequirefrom '@pkgr/core', which provides a way to use CommonJS-style requires in an ESM context. This is essential for the migration to ESM while maintaining compatibility with existing CommonJS modules.
14-14: Updated import paths with .js extension for ESM compatibility.Added
.jsextensions to import paths, which is required for proper module resolution in ESM. This ensures that the modules are correctly resolved when imported in an ESM context.Also applies to: 16-17
36-40: Converted types to exported interfaces.Changed from local types to exported interfaces for
LegacyResolver,LegacyResolverObject, andLegacyResolverRecord. This improves module interoperability by making these types available to other modules, which is beneficial in a large codebase.Also applies to: 42-58, 60-65
201-201: Updated require calls to use cjsRequire for ESM compatibility.Changed from
require.resolveandrequiretocjsRequire.resolveandcjsRequirerespectively. This modification allows for CommonJS-style module loading in an ESM context, which is necessary during the transition to ESM modules.Also applies to: 206-206, 215-215
test/rules/dynamic-import-chunkname.spec.ts (4)
1-1: ESM migration: Added cjsRequire importAdded import from
@pkgr/coreto support CommonJS modules in an ESM environment. This allows for compatibility with packages that still use CommonJS exports.
4-4: Added TypeScript type importAdded TSESLint type import to improve type safety and provide better typing for the parser module.
6-7: Updated import paths with .js extensionModified import paths to include explicit
.jsextensions, which is required for proper module resolution in ESM environments.
43-43: Replaced require with cjsRequire for better type safetyReplaced the direct CommonJS
require()call with the typedcjsRequire<TSESLint.Parser.LooseParserModule>()function, enhancing type safety while maintaining compatibility with CommonJS modules.src/rules/no-duplicates.ts (8)
1-1: ESM migration: Added cjsRequire importAdded import from
@pkgr/coreto support CommonJS modules in an ESM environment.
3-3: Changed semver import to namespace importModified the import of
semverfrom a default import to a namespace import, which aligns better with how the semver package is structured and with ESM best practices.
6-7: Updated import paths with .js extensionAdded explicit
.jsextensions to import paths, which is a requirement for proper module resolution in ESM.
15-15: Using cjsRequire for TypeScript packageReplaced direct
requirewithcjsRequirefor loading the TypeScript package.json, ensuring compatibility with ESM.
23-26: Converted Options type to exported interfaceChanged
type Optionstoexport interface Options, making it explicitly available to other modules. This improves API documentation and TypeScript's ability to import this type.
28-28: Exported MessageId typeChanged
type MessageIdtoexport type MessageIdto make it explicitly available to other modules.
397-403: Converted ModuleMap type to exported interfaceChanged
type ModuleMaptoexport interface ModuleMap, making it available to other modules. Using an interface is more appropriate here since it's a complex object structure.
405-405: Updated export style to ESM default exportChanged from CommonJS-style
export =to ESMexport default, which is the standard way to export a default value in ECMAScript Modules.src/rules/no-rename-default.ts (4)
11-12: Updated import paths with .js extensionAdded explicit
.jsextensions to import paths for ESM compatibility. This ensures proper module resolution in an ESM environment.
14-16: Exported Options typeChanged
type Optionstoexport type Options, making it explicitly available to other modules. This improves the public API of the module.
18-18: Exported MessageId typeChanged
type MessageIdtoexport type MessageIdto make it explicitly available to other modules.
20-20: Updated export style to ESM default exportChanged from CommonJS-style
export =to ESMexport default, conforming to the ECMAScript Modules standard.src/rules/namespace.ts (6)
1-1: Enhanced type importsUpdated import to include both
TSESTreeandTSESLinttypes, enhancing type coverage for the rule implementation.
9-9: Updated import path with .js extensionAdded explicit
.jsextension to the import path, required for proper module resolution in ESM.
11-17: Exported MessageId typeChanged
type MessageIdtoexport type MessageIdto make it explicitly available to other modules, enhancing the public API.
19-21: Converted Options type to exported interfaceChanged
type Optionstoexport interface Options, making it available to other modules and clearly indicating its structure.
24-24: Enhanced function parameter typingUpdated the type annotation for the
contextparameter to use the more specificTSESLint.RuleContext<MessageId, [Options]>type, which includes the options interface and improves type safety.
101-101: Updated export style to ESM default exportChanged from CommonJS-style
export =to ESMexport default, aligning with ECMAScript Modules standards.test/rules/consistent-type-specifier-style.spec.ts (4)
1-1: Add cjsRequire to support CommonJS imports in ESMThe addition of
cjsRequirefrom@pkgr/coreenables the code to dynamically load CommonJS modules within an ESM context, which is necessary for the migration to ESM.
5-6: Update import paths to include file extensionsAdding
.jsextensions to import paths is required for ESM compatibility. This is a necessary change as part of the migration from CommonJS to ESM modules.
403-403: Replace require with cjsRequire for parser loadingChanging from
require(parsers.BABEL)tocjsRequire(parsers.BABEL)enables dynamic loading of CommonJS modules in an ESM context. This is essential for maintaining compatibility with the existing Babel parser setup during the ESM migration.
425-425: Replace require with cjsRequire for Hermes parser loadingSimilar to the Babel parser change, replacing
require(parsers.HERMES)withcjsRequire(parsers.HERMES)maintains the ability to dynamically load the Hermes parser in an ESM context.src/rules/no-commonjs.ts (4)
7-7: Update utility import path to include file extensionAdding the
.jsextension to the import path is required for ESM compatibility. This is a necessary change as part of migrating from CommonJS to ESM modules.
9-13: Convert type definition to exported interfaceChanging from a local type definition to an exported interface improves module interoperability by making
NormalizedOptionsavailable for import by other modules. This is consistent with modern TypeScript best practices for ESM.
15-15: Export the Options type for external consumptionMaking the
Optionstype explicitly exported allows it to be imported by other modules, which is important for ESM compatibility and improves the API surface of the module.
66-66: Change from CommonJS export to ESM default exportReplacing
export =withexport defaultis a critical change for ESM compatibility. This modernizes the export syntax while maintaining the same functionality.test/rules/no-unused-modules.spec.ts (3)
3-4: Add ESM-compatible imports for Jest and CommonJS requireThese imports are necessary for the ESM migration:
jestis now imported from@jest/globalsinstead of relying on the global Jest objectcjsRequireis imported asrequireto maintain the same function signature while supporting ESM contextThis approach ensures backward compatibility while moving forward with ESM.
🧰 Tools
🪛 GitHub Actions: CI
[error] SyntaxError: The requested module 'eslint/use-at-your-own-risk' does not provide an export named 'FileEnumerator'
8-9: Add ESLint import with appropriate warning commentThe import for
eslint8UnsupportedApihas been properly marked with an ESLint disable comment that explains why the rule is being disabled specifically for this import. This helps maintain code quality while acknowledging the necessary exception.🧰 Tools
🪛 GitHub Actions: CI
[error] SyntaxError: The requested module 'eslint/use-at-your-own-risk' does not provide an export named 'FileEnumerator'
12-13: Update utility imports with file extensionsAdding
.jsextensions to the import paths from../utils.jsensures compatibility with ESM module resolution, which requires explicit file extensions for relative imports.🧰 Tools
🪛 GitHub Actions: CI
[error] SyntaxError: The requested module 'eslint/use-at-your-own-risk' does not provide an export named 'FileEnumerator'
src/rules/no-cycle.ts (6)
5-5: Update type imports to include file extensionAdding the
.jsextension to the import path for type declarations ensures compatibility with ESM module resolution, which requires explicit file extensions.
6-13: Update utility imports to include file extensionThe import statement has been updated to specify the full path with
.jsextension, which is required for ESM compatibility.
15-19: Convert type definition to exported interface extending ModuleOptionsChanging from a local type definition to an exported interface that extends
ModuleOptionsimproves module interoperability and follows TypeScript best practices. This makes theOptionsinterface available for import by other modules and provides better type inheritance.
21-21: Export MessageId type for external consumptionMaking the
MessageIdtype explicitly exported allows it to be imported by other modules, which is important for ESM compatibility and API consistency.
23-26: Export Traverser interface for external consumptionMaking the
Traverserinterface explicitly exported allows it to be imported by other modules, which improves API consistency and transparency.
30-30: Change from CommonJS export to ESM default exportReplacing
export =withexport defaultis a key change for ESM compatibility. This modernizes the export syntax while maintaining the same functionality.test/rules/order.spec.ts (5)
1-1: Good approach for ESM compatibilityUsing both
cjsRequiredirectly and aliasing it asrequireprovides a clean transition path to ESM while maintaining compatibility with existing code patterns.
4-4: Good addition of TypeScript utility typesAdding the
TSESLinttype import enhances type safety in the test file, particularly useful for the parser configuration later in the file.
11-12: Correct update of import paths with explicit file extensionsAdding
.jsextensions to import paths is necessary for ESM compatibility, as ESM requires explicit file extensions unlike CommonJS.
20-20: Proper adaptation of parser configurationUsing
cjsRequire(parsers.BABEL)instead of directrequirealigns with the ESM migration strategy and maintains consistent use of the imported utility.
3154-3156: Enhanced type safety for parser configurationUsing the generic type parameter
<TSESLint.Parser.LooseParserModule>with require improves type safety when configuring the parser for TypeScript tests.src/rules/no-extraneous-dependencies.ts (7)
8-8: Update to import paths properly includes .js extensionsThe imports now use ".js" file extensions, which is required for proper ESM module resolution. This change is consistent with the migration to ESM as the primary module system.
Also applies to: 16-16
18-18: Export type for better reusabilityConverting
PackageDepsfrom a local type to an exported one enhances reusability and API clarity. This is a good practice when migrating to ESM modules.
150-156: Interface exported for better module interoperabilityConverting
DepDeclarationfrom a local type to an exported interface improves the module's API surface and allows for consumption by external modules. This follows modern TypeScript best practices.
203-210: Interface exported for better module interoperabilitySimilarly, exporting the
DepsOptionsinterface enhances the module's public API and makes the type definitions more accessible for external consumers.
344-353: Interface exported for better module interoperabilityExporting the
Optionsinterface is consistent with the pattern applied to other types and improves the overall type system accessibility.
355-360: MessageId type is now exportedThe MessageId type is now exported, which is consistent with the pattern seen in other rule files. This allows for better type checking and integration with the rule system.
362-362: Updated export syntax to ESM default exportChanged from CommonJS-style
export =to ESM-styleexport default, which is necessary for proper ES module compatibility. This is a key part of the ESM migration.package.json (9)
4-4: Set module type to ESMSetting "type": "module" is the fundamental change for migrating to ESM as primary. This configuration tells Node.js to interpret all .js files as ES modules by default.
13-14: Updated entry points to support dual package modeChanging the main entry point to "lib/index.cjs" and adding a module entry pointing to "lib/index.js" enables the package to work in both CommonJS and ESM environments, with ESM being the primary format.
16-35: Comprehensive exports configuration for multi-environment compatibilityThe exports field has been restructured to properly support different module environments:
- Import for ESM consumers
- Module-sync for specialized module systems
- Require for CommonJS consumers
- Exposing specific modules like config, rules, and utils
This configuration ensures maximum compatibility while prioritizing ESM.
36-36: Added types field for TypeScript integrationSpecifying the types field helps TypeScript consumers correctly resolve type definitions, enhancing the package's usability in typed environments.
38-38: Added CommonJS type definition fileIncluding "index.d.cts" in the files list provides type definitions for CommonJS consumers, ensuring type safety in all environments.
53-55: Updated build scripts for modern toolingThe build scripts now use parallel execution and include a new rollup-based build step ("build:r"). This allows for more efficient builds and better module output.
61-61: Updated TypeScript configuration referenceChanged from "tsconfig.base.json" to "tsconfig.lib.json" to likely reference a more specific configuration for library builds.
64-65: Updated test commands for ESM compatibilityAdded Node.js flags to support ESM modules in Jest testing and updated the test-compiled command. These changes ensure tests run correctly in the new module system.
168-182: Added ESLint ignore configurationAdded eslintIgnore field to exclude certain files and directories from linting. This improves the development workflow by preventing linting errors in generated or test files.
src/rules/extensions.ts (6)
3-3: Updated import paths with .js extensionsImport paths now include the ".js" extension, which is required for ESM module resolution. This is consistent with the ESM migration across the codebase.
Also applies to: 11-11
38-40: Exported types for better module interoperabilityConverting
ModifierandModifierByFileExtensionfrom local types to exported types enhances their reusability and makes the public API more comprehensive.
42-46: Exported interfaces for options typesConverting options-related types to exported interfaces improves API clarity and allows for reuse in other modules. This follows modern TypeScript practices for module design.
Also applies to: 48-51
53-60: Exported options and normalized options typesExporting the
OptionsandNormalizedOptionstypes provides better type visibility to consumers and follows the pattern seen across other rule files.Also applies to: 61-66
68-68: Exported MessageId typeThe MessageId type export follows the consistent pattern established in other rule files, enhancing type safety and interoperability.
137-137: Updated export syntax to ESM default exportChanged from CommonJS export to ESM default export, which is necessary for proper ES module compatibility and consistent with the migration pattern across the codebase.
src/utils/index.ts (3)
1-13: Updated exports with .js file extensionsAll export statements now include ".js" file extensions, which is required for proper ESM module resolution. This ensures compatibility with ESM import requirements.
14-15: Added exports for new utility modulesThe barrel file now exports two new modules:
lazy-value.jsandlegacy-resolver-settings.js. These additions enhance the utility library's capabilities while maintaining the ESM export pattern.
16-25: Remaining exports updated with .js extensionsConsistently updated all remaining export statements with ".js" extensions, completing the migration to proper ESM export syntax throughout the barrel file.
src/types.ts (20)
6-11: Import paths updated to use.jsextension for ESM compatibilityThe import paths now include
.jsextensions which is required for proper ESM module resolution. This is a necessary change when migrating from CommonJS to ESM modules, as ESM requires explicit file extensions.
33-33: Export path correctly updated with.jsextensionThe export path now includes the
.jsextension, maintaining consistency with ESM module resolution requirements.
37-41: Type converted to interface forNodeResolverOptionsThe
NodeResolverOptionsdefinition has been changed from a type alias to an interface. This is a good practice as interfaces are generally preferred for object types that could be extended in the future.
43-48: Type converted to interface forWebpackResolverOptionsThe conversion from type to interface for
WebpackResolverOptionshelps maintain consistency across the codebase and follows TypeScript best practices for object type definitions.
50-54: Interface definition forTsResolverOptionscorrectly extendsResolveOptionsThe
TsResolverOptionsinterface now properly extendsResolveOptionswhile maintaining the same properties. This change aligns with the shift from type aliases to interfaces.
63-68:NewResolverconverted from type to interfaceThe conversion from type to interface for
NewResolveris appropriate for an object structure with properties. The functionality remains unchanged while following TypeScript best practices.
76-79: Result interfaces split into separate interface declarations
ResultNotFoundandResultFoundhave been converted from type aliases to interfaces. This provides better clarity and follows the pattern of using interfaces for object types throughout the codebase.Also applies to: 81-84
90-105:ImportSettingsconverted to interface with preserved structureThe
ImportSettingstype has been converted to an interface while maintaining all its properties and optional flags. This change is part of the consistent pattern of using interfaces for object types.
115-119:PluginConfiginterface now extendsTSESLint.ClassicConfig.ConfigThe conversion to an interface for
PluginConfigproperly maintains the extension of the ESLint config interface. This change aligns with the project-wide shift to interfaces for object types.
121-124: Flat config interfaces clearly separatedThe conversion of
PluginFlatBaseConfigandPluginFlatConfigto interfaces maintains their relationship while following the new pattern. This change enhances future extensibility of these configurations.Also applies to: 126-128
130-135:RuleContextinterface maintains generic parametersThe
RuleContextinterface correctly preserves the generic type parameters while extending the ESLint rule context. The structure and functionality remain unchanged.
137-145:ChildContextconverted to interfaceThe conversion from type to interface for
ChildContextmaintains all its properties and structure while following the codebase's new pattern.
147-150:ParseErrorinterface extendsErrorThe conversion to an interface for
ParseErrorcorrectly maintains its extension of the baseErrortype with additional properties for line number and column.
152-155:CustomESTreeNodegeneric interface properly definedThe
CustomESTreeNodehas been converted from a type to an interface while maintaining its generic type parameter and extension of the Omit type. This change is consistent with the project's new pattern.
159-162:ExportNamespaceSpecifierinterface directly extendsCustomESTreeNodeThe
ExportNamespaceSpecifieris now defined as an interface that extendsCustomESTreeNoderather than using type composition. This provides better type safety and clarity.
164-169:PathGroupconverted to interfaceThe conversion from type to interface for
PathGroupmaintains all its properties and structure, following the consistent pattern in this file.
181-188:NamedOptionsconverted to interfaceThe
NamedOptionsdefinition has been changed from a type alias to an interface while preserving all its properties and optional flags.
190-194:AlphabetizeOptionsconverted to interfaceThe conversion to an interface for
AlphabetizeOptionsmaintains all its properties while following the file's consistent pattern of using interfaces for object types.
206-216: Import entry interfaces properly definedThe conversion of
ImportEntryandImportEntryWithRankto interfaces preserves their structure and relationship, withImportEntryWithRankeffectively extendingImportEntrywith additional properties.Also applies to: 218-221
223-228: Ranks-related interfaces properly definedThe conversion of
RanksPathGroupandRanksto interfaces maintains their structure and relationship while following the codebase's new pattern of using interfaces for object types.Also applies to: 232-237
JounQin
force-pushed
the
feat/esm_primary
branch
2 times, most recently
from
f4cfc3c to
e93ddf7
Compare
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #271 +/- ##
==========================================
- Coverage 96.18% 95.99% -0.20%
==========================================
Files 106 91 -15
Lines 5037 4745 -292
Branches 1779 1785 +6
==========================================
- Hits 4845 4555 -290
+ Misses 191 189 -2
Partials 1 1 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (3)
src/rules/no-import-module-exports.ts (1)
3-3: Good update fromrequire.resolvetocjsRequire.resolveThe replacement of Node.js built-in
require.resolvewithcjsRequire.resolvefrom@pkgr/corealigns with the ESM migration, allowing CommonJS-style resolution in an ESM environment.However, note that line 18 in comments still references
require.resolvewhich should be updated for consistency.- // in which case require.resolve would throw. + // in which case cjsRequire.resolve would throw.Also applies to: 15-15
eslint.config.js (2)
17-19: Consider using a more robust version comparisonThe current version comparison approach works, but could be more robust using semantic versioning comparison.
-const { version } = cjsRequire('eslint/package.json') - -const nonLatestEslint = +version.split('.')[0] < 9 +const { version } = cjsRequire('eslint/package.json') + +// Use semver comparison or more explicit version parsing +const majorVersion = +version.split('.')[0] +const nonLatestEslint = majorVersion < 9
49-54: Consider consolidating import resolver configurationsThe import resolver configuration appears in two places (both here and in lines 146-151), which might lead to maintenance issues. Consider consolidating these configurations or documenting why they're separate.
Is there a specific reason for having separate resolver configurations? If they serve different purposes, consider adding comments explaining the difference, otherwise consider consolidating them.
Also applies to: 146-151
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (23)
eslint.config.js(1 hunks)src/node-resolver.ts(2 hunks)src/rules/export.ts(3 hunks)src/rules/extensions.ts(3 hunks)src/rules/group-exports.ts(2 hunks)src/rules/named.ts(1 hunks)src/rules/no-absolute-path.ts(1 hunks)src/rules/no-amd.ts(1 hunks)src/rules/no-cycle.ts(1 hunks)src/rules/no-duplicates.ts(2 hunks)src/rules/no-dynamic-require.ts(2 hunks)src/rules/no-extraneous-dependencies.ts(5 hunks)src/rules/no-import-module-exports.ts(2 hunks)src/rules/no-mutable-exports.ts(1 hunks)src/rules/no-named-as-default.ts(1 hunks)src/rules/no-self-import.ts(2 hunks)src/rules/no-unused-modules.ts(4 hunks)src/rules/no-useless-path-segments.ts(2 hunks)src/types.ts(12 hunks)test/cli.spec.ts(4 hunks)test/fixtures/yarn-pnp/eslint.config.js(1 hunks)test/utils/resolve.spec.ts(3 hunks)tsconfig.base.json(1 hunks)
🚧 Files skipped from review as they are similar to previous changes (18)
- src/rules/no-dynamic-require.ts
- src/rules/no-unused-modules.ts
- src/rules/export.ts
- test/utils/resolve.spec.ts
- src/rules/no-absolute-path.ts
- src/rules/no-named-as-default.ts
- src/node-resolver.ts
- tsconfig.base.json
- test/cli.spec.ts
- src/rules/no-self-import.ts
- src/rules/no-mutable-exports.ts
- src/rules/no-duplicates.ts
- src/rules/group-exports.ts
- src/rules/no-cycle.ts
- src/rules/named.ts
- src/rules/extensions.ts
- src/rules/no-useless-path-segments.ts
- src/rules/no-extraneous-dependencies.ts
🧰 Additional context used
🧬 Code Definitions (3)
test/fixtures/yarn-pnp/eslint.config.js (1)
src/node-resolver.ts (1)
createNodeResolver(33-85)
src/rules/no-amd.ts (16)
src/rules/no-mutable-exports.ts (1)
MessageId(5-5)src/rules/newline-after-import.ts (1)
MessageId(83-83)src/rules/no-absolute-path.ts (1)
MessageId(11-11)src/rules/no-import-module-exports.ts (1)
MessageId(49-49)src/rules/no-extraneous-dependencies.ts (1)
MessageId(355-360)src/rules/no-duplicates.ts (1)
MessageId(28-28)src/rules/no-useless-path-segments.ts (1)
MessageId(46-46)src/rules/named.ts (1)
MessageId(8-8)src/rules/no-cycle.ts (1)
MessageId(21-21)src/rules/no-named-as-default.ts (1)
MessageId(5-5)src/rules/no-self-import.ts (1)
MessageId(10-10)src/rules/no-dynamic-require.ts (1)
MessageId(37-37)src/rules/export.ts (1)
MessageId(111-111)src/rules/extensions.ts (1)
MessageId(68-68)src/rules/group-exports.ts (1)
MessageId(38-38)src/rules/dynamic-import-chunkname.ts (1)
MessageId(14-22)
src/rules/no-import-module-exports.ts (3)
src/types.ts (1)
RuleContext(130-135)src/utils/pkg-up.ts (1)
pkgUp(24-26)src/utils/create-rule.ts (1)
createRule(14-14)
🔇 Additional comments (35)
src/rules/no-amd.ts (3)
5-5: Correctly updated import path for ESM compatibility.The import statement now includes the explicit
.jsfile extension, which is required for ESM compatibility. This aligns with the PR objective of migrating to ECMAScript Modules as the primary module system.
7-7: Proper type export for enhanced modularity.Exporting the
MessageIdtype follows the pattern established across other rule files and improves type accessibility across the codebase. This change enhances the module's API and allows for better type checking when consumed by other modules.
9-9: Successfully migrated from CommonJS to ESM export syntax.Changed the export style from CommonJS (
export =) to ESM (export default), which is a key part of the ESM migration objective. This ensures the rule can be properly imported using standard ESM import syntax in other files.src/rules/no-import-module-exports.ts (2)
7-8: Correctly added.jsextensions to imports for ESM compatibilityAdding explicit
.jsextensions to import paths is necessary for ESM modules, as they require file extensions unlike CommonJS. This change ensures proper module resolution in an ESM environment.
45-47: Appropriate export changes for ESM compatibilityThe changes to export types and the rule itself are well-aligned with ESM migration:
- Converting local types to exported interfaces/types improves reusability
- Changing from
export =(CommonJS) toexport default(ESM) ensures compatibility with ESM import syntaxThese changes maintain the same functionality while making the module properly consumable in an ESM context.
Also applies to: 49-49, 51-51
test/fixtures/yarn-pnp/eslint.config.js (3)
1-4: Great use of named imports for better ESM practicesThe change to use named imports for
configsandcreateNodeResolveraligns with ESM best practices, making dependencies more explicit and improving code readability.
10-10: Direct usage of the named importGood refactoring to use
createNodeResolver()directly instead of accessing it throughimportPlugin.createNodeResolver(). This reduces indirection and makes the code more maintainable.
16-16: Clean up of configuration spreadUsing the named import
configs.recommended.rulesdirectly simplifies the code and makes it more readable than the previous approach of accessing throughimportPlugin.configs.recommended.rules.eslint.config.js (5)
1-16: Well-structured ESLint flat config setup with comprehensive plugin importsThe new ESLint configuration file correctly uses the modern flat config format, importing all necessary plugins and utilities for a comprehensive linting setup. This approach is well-aligned with the ESM migration goals of the PR.
65-65: Good compatibility handling for ESLint versionsThe conditional rule configuration based on ESLint version is a good approach to handle compatibility issues during migration.
121-126: Good TypeScript import style enforcementThe use of
consistent-type-importswithinline-type-importsstyle is a good practice for TypeScript projects, ensuring that type imports are clearly distinguished from value imports.
134-143: Well-configured import ordering rulesThe import ordering configuration with alphabetization and required spacing between import groups will help maintain code organization and readability.
154-166: Comprehensive file-specific configurationsThe configuration correctly includes specific rule overrides for different file types and special files, which is a best practice for ESLint configuration. This ensures appropriate linting based on file context.
Also applies to: 167-172, 173-178, 179-185
src/types.ts (22)
7-7: Use of explicit.jsextension for ESM imports
The switch to the.jsextension in these import statements aligns with the PR's objective to adopt ESM as the primary module system. This ensures proper resolution under ESM.Also applies to: 10-11
33-33: Consistent ESM import style
Continuing the same practice here helps maintain consistency in the new ESM-based import approach.
37-41: Switch from type to interface: NodeResolverOptions
DefiningNodeResolverOptionsas an interface instead of a type provides better extensibility. No issues found.
43-48: Switch from type to interface: WebpackResolverOptions
Interfaces typically handle merging and augmentation more gracefully than types. Looks good.
50-54: Extended and updated: TsResolverOptions
Migrating to an interface and extendingResolveOptionsappears correct. No conflicts detected.
63-68: Refined declaration: NewResolver
Changing this to an interface increases clarity and preserves future expandability.
77-79: Refined declaration: ResultNotFound
A straightforward interface to represent a “not found” resolution. Implementation is clear.
81-84: Refined declaration: ResultFound
Mirroring “not found” with a “found” interface is consistent. LGTM.
90-105: Refined declaration: ImportSettings
Switching to an interface should help with incremental additions of settings. No immediate concerns.
115-119: Refined declaration: PluginConfig
This interface nicely extendsTSESLint.ClassicConfig.Config. The explicit use ofPluginNameis consistent with other changes.
121-124: Refined declaration: PluginFlatBaseConfig
Continuing the interface approach remains consistent. Looks good.
130-135: Refined declaration: RuleContext
Omittingsettingsfrom the core rule context and reintroducing it for plugin usage is a clean design.
137-145: Refined declaration: ChildContext
Defining these properties in an interface should streamline the resolution logic.
147-150: Refined declaration: ParseError
Inheriting fromErroris valid and preserves typed error properties. Good use of an interface.
152-155: Refined declaration: CustomESTreeNode
Interfaces are well-suited to represent AST nodes that merge in multiple fields. Nicely done.
159-162: Refined declaration: ExportNamespaceSpecifier
Exporting it as an interface clarifies usage across the codebase.
181-188: Refined declaration: NamedOptions
Interface approach is consistent with the rest of the migration and fosters extensibility.
190-194: Refined declaration: AlphabetizeOptions
Defines sorting logic in a maintainable way. Great consistency with the rest of the file.
206-216: Refined declaration: ImportEntry
An interface is a solid choice for describing the shape of imports. No issues found.
218-221: Refined declaration: ImportEntryWithRank
ExtendingImportEntryclarifies the ranking concept. This interface usage looks good.
223-228: Refined declaration: RanksPathGroup
Interfaces support partial merges and extension nicely, which can be beneficial here.
232-237: Refined declaration: Ranks
The final interface in the file echoes the consistent approach. Nicely done.
JounQin
force-pushed
the
feat/esm_primary
branch
2 times, most recently
from
a49839f to
4fd308d
Compare
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (2)
eslint.config.js (2)
49-53: Consider consolidating duplicate TypeScript project configuration.The TypeScript project configuration is specified in two places (for different resolvers). This duplication could lead to maintenance issues if the project structure changes.
+ // Define TypeScript project config once + const tsProject = 'tsconfig.base.json'; + { plugins: { 'eslint-plugin': eslintPlugin, }, settings: { 'import-x/resolver-next': [ createTypeScriptImportResolver({ - project: 'tsconfig.base.json', + project: tsProject, }), ], }, // ... }, { files: ['**/*.ts'], // ... settings: { 'import-x/resolver': { typescript: { - project: 'tsconfig.base.json', + project: tsProject, }, }, }, },Also applies to: 145-151
168-172: Consider adding explicit configuration for .mjs files.While you've added configuration for CommonJS files (
.cjs,.cts), consider also adding explicit settings for.mjsfiles to ensure complete module type coverage, given the migration to ESM.{ files: ['**/*.{cjs,cts}'], languageOptions: { globals: globals.node, }, }, + { + files: ['**/*.{mjs,mts}'], + languageOptions: { + globals: globals.node, + }, + },
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (25)
eslint.config.js(1 hunks)src/node-resolver.ts(2 hunks)src/rules/export.ts(3 hunks)src/rules/extensions.ts(3 hunks)src/rules/group-exports.ts(2 hunks)src/rules/named.ts(1 hunks)src/rules/no-absolute-path.ts(1 hunks)src/rules/no-amd.ts(1 hunks)src/rules/no-cycle.ts(1 hunks)src/rules/no-duplicates.ts(2 hunks)src/rules/no-dynamic-require.ts(2 hunks)src/rules/no-extraneous-dependencies.ts(5 hunks)src/rules/no-import-module-exports.ts(2 hunks)src/rules/no-mutable-exports.ts(1 hunks)src/rules/no-named-as-default.ts(1 hunks)src/rules/no-self-import.ts(2 hunks)src/rules/no-unused-modules.ts(4 hunks)src/rules/no-useless-path-segments.ts(2 hunks)src/types.ts(12 hunks)src/utils/docs-url.ts(1 hunks)test/cli.spec.ts(4 hunks)test/fixtures.spec.ts(1 hunks)test/fixtures/yarn-pnp/eslint.config.js(1 hunks)test/utils/resolve.spec.ts(3 hunks)tsconfig.base.json(1 hunks)
✅ Files skipped from review due to trivial changes (1)
- test/fixtures.spec.ts
🚧 Files skipped from review as they are similar to previous changes (22)
- src/utils/docs-url.ts
- src/rules/no-mutable-exports.ts
- test/fixtures/yarn-pnp/eslint.config.js
- src/rules/no-absolute-path.ts
- src/rules/no-dynamic-require.ts
- src/rules/no-useless-path-segments.ts
- src/rules/no-amd.ts
- src/node-resolver.ts
- src/rules/no-duplicates.ts
- src/rules/named.ts
- tsconfig.base.json
- src/rules/no-unused-modules.ts
- src/rules/no-named-as-default.ts
- src/rules/no-cycle.ts
- test/utils/resolve.spec.ts
- test/cli.spec.ts
- src/rules/no-self-import.ts
- src/rules/export.ts
- src/rules/no-extraneous-dependencies.ts
- src/rules/extensions.ts
- src/rules/group-exports.ts
- src/types.ts
🧰 Additional context used
🧬 Code Definitions (1)
src/rules/no-import-module-exports.ts (3)
src/types.ts (1)
RuleContext(130-135)src/utils/pkg-up.ts (1)
pkgUp(24-26)src/utils/create-rule.ts (1)
createRule(14-14)
⏰ Context from checks skipped due to timeout of 90000ms (2)
- GitHub Check: Lint and Test with Node.js 20 and ESLint 8.56 on windows-latest
- GitHub Check: Lint and Test with Node.js 20 and ESLint 9 on windows-latest
🔇 Additional comments (10)
src/rules/no-import-module-exports.ts (6)
3-3: Good ESM migration change: CommonJS require replacementAdding
cjsRequirefrom '@pkgr/core' is a good approach for maintaining CommonJS compatibility during the migration to ESM. This utility will be used to replace the native Node.jsrequirefunctionality.
7-8: ESM migration: Import paths properly updated with extensionsUpdating import paths to include '.js' extensions is required for ESM compatibility as file extensions are mandatory in import paths.
15-15: ESM compatibility: Updated resolver functionReplacing
require.resolvewithcjsRequire.resolvemaintains the same functionality while using the ESM-compatible utility imported above.
45-47: Improved type exposure: Options interface now exportedConverting the local Options type to an exported interface improves its reusability and makes it available to other modules, which is good for API design.
49-49: Improved type exposure: MessageId now exportedMaking the MessageId type exported improves API clarity and allows it to be used by consumers of this module.
51-51: ESM migration: Updated export syntaxChanging from
export =(TypeScript's CommonJS-specific syntax) toexport default(standard ESM syntax) is necessary for ESM compatibility. This change will require consumers to update their import statements accordingly.Consumers of this rule will need to change their imports from:
import noImportModuleExports from 'eslint-plugin-import-x/rules/no-import-module-exports'to:
import noImportModuleExports from 'eslint-plugin-import-x/rules/no-import-module-exports.js'or for internal imports:
import noImportModuleExports from '../rules/no-import-module-exports.js'eslint.config.js (4)
3-16: Good overall import structure for the ESM migration.The imports are well-organized and properly structured using ESM syntax, which aligns with the PR objective of migrating to ESM as the primary module system. The use of named imports from packages enhances code readability and maintainability.
17-19: Version detection approach for ESLint compatibility is pragmatic.The code intelligently detects the ESLint version and sets a flag (
nonLatestEslint) to handle rule differences between major versions, which is a good approach for ensuring compatibility across environments.
21-186: Excellent ESLint flat config structure that supports the ESM migration.The overall configuration is well-structured with:
- Proper separation of concerns using file patterns
- Comprehensive plugin integration
- Type-aware linting with TypeScript
- Appropriate rule customization for different file types
- ESM-friendly configuration
This structure will facilitate further migrations and maintenance, aligning perfectly with the PR objective to migrate to ESM as the primary module system.
1-1: Why botheslintrc.cjsandeslint.config.js?
JounQin
force-pushed
the
feat/esm_primary
branch
2 times, most recently
from
9660942 to
d80d534
Compare
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (1)
eslint.config.js (1)
17-19: Consider using ESM dynamic import instead ofcjsRequireWhile this works, using
cjsRequirefrom@pkgr/coreseems to mix CommonJS patterns with ESM. For a full ESM migration, consider using dynamic import or other ESM-compatible approaches.-const { version } = cjsRequire('eslint/package.json') +// Use dynamic import for ESM compatibility +const { version } = await import('eslint/package.json', { assert: { type: 'json' } })Note: This would require making the configuration file an async function or using top-level await (which requires Node.js 14.8.0+).
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (29)
eslint.config.js(1 hunks)src/meta.ts(1 hunks)src/node-resolver.ts(2 hunks)src/rules/export.ts(3 hunks)src/rules/extensions.ts(3 hunks)src/rules/group-exports.ts(2 hunks)src/rules/named.ts(1 hunks)src/rules/no-absolute-path.ts(1 hunks)src/rules/no-amd.ts(1 hunks)src/rules/no-cycle.ts(1 hunks)src/rules/no-duplicates.ts(2 hunks)src/rules/no-dynamic-require.ts(2 hunks)src/rules/no-extraneous-dependencies.ts(5 hunks)src/rules/no-import-module-exports.ts(2 hunks)src/rules/no-mutable-exports.ts(1 hunks)src/rules/no-named-as-default.ts(1 hunks)src/rules/no-self-import.ts(2 hunks)src/rules/no-unused-modules.ts(4 hunks)src/rules/no-useless-path-segments.ts(2 hunks)src/types.ts(12 hunks)src/utils/declared-scope.ts(2 hunks)src/utils/docs-url.ts(1 hunks)src/utils/module-visitor.ts(2 hunks)src/utils/resolve.ts(2 hunks)test/cli.spec.ts(4 hunks)test/fixtures.spec.ts(1 hunks)test/fixtures/yarn-pnp/eslint.config.js(1 hunks)test/utils/resolve.spec.ts(3 hunks)tsconfig.base.json(1 hunks)
🚧 Files skipped from review as they are similar to previous changes (27)
- test/fixtures.spec.ts
- src/utils/module-visitor.ts
- test/fixtures/yarn-pnp/eslint.config.js
- src/utils/declared-scope.ts
- src/utils/resolve.ts
- src/utils/docs-url.ts
- src/node-resolver.ts
- tsconfig.base.json
- src/rules/no-self-import.ts
- src/rules/export.ts
- src/rules/no-amd.ts
- test/utils/resolve.spec.ts
- src/rules/no-named-as-default.ts
- test/cli.spec.ts
- src/rules/named.ts
- src/rules/no-cycle.ts
- src/rules/no-useless-path-segments.ts
- src/rules/no-mutable-exports.ts
- src/meta.ts
- src/rules/no-unused-modules.ts
- src/rules/no-dynamic-require.ts
- src/rules/group-exports.ts
- src/rules/no-absolute-path.ts
- src/rules/extensions.ts
- src/rules/no-import-module-exports.ts
- src/rules/no-extraneous-dependencies.ts
- src/types.ts
🧰 Additional context used
🧠 Learnings (1)
eslint.config.js (1)
Learnt from: JounQin
PR: un-ts/eslint-plugin-import-x#271
File: test/rules/no-unused-modules.spec.ts:1528-1532
Timestamp: 2025-03-30T09:06:59.006Z
Learning: The import from 'eslint8.56/use-at-your-own-risk' has incorrect TypeScript types but works correctly at runtime, which is properly handled with a `@ts-expect-error` comment.
🧬 Code Definitions (2)
eslint.config.js (1)
src/meta.ts (1)
cjsRequire(10-12)
src/rules/no-duplicates.ts (19)
src/rules/no-cycle.ts (2)
Options(15-19)MessageId(21-21)src/rules/no-extraneous-dependencies.ts (2)
Options(344-353)MessageId(355-360)src/rules/dynamic-import-chunkname.ts (2)
Options(8-12)MessageId(14-22)src/rules/no-unassigned-import.ts (2)
Options(29-31)ImportDeclaration(74-81)src/rules/order.ts (2)
Options(1140-1152)ImportDeclaration(1462-1498)src/rules/extensions.ts (2)
Options(53-59)MessageId(68-68)src/rules/no-dynamic-require.ts (2)
Options(30-32)MessageId(34-34)src/rules/no-commonjs.ts (1)
Options(15-15)src/rules/namespace.ts (1)
Options(19-21)src/rules/no-restricted-paths.ts (1)
Options(35-43)src/rules/no-absolute-path.ts (1)
MessageId(11-11)src/rules/named.ts (1)
MessageId(8-8)src/rules/no-self-import.ts (1)
MessageId(10-10)src/rules/group-exports.ts (1)
MessageId(38-38)src/rules/no-amd.ts (1)
MessageId(7-7)src/rules/no-named-as-default.ts (1)
MessageId(5-5)src/rules/no-mutable-exports.ts (1)
MessageId(5-5)src/rules/no-named-default.ts (1)
ImportDeclaration(21-45)src/utils/create-rule.ts (1)
createRule(14-14)
⏰ Context from checks skipped due to timeout of 90000ms (5)
- GitHub Check: Lint and Test with Node.js 20 and ESLint 9 on windows-latest
- GitHub Check: Lint and Test with Node.js 18 and ESLint 8.56 on windows-latest
- GitHub Check: Lint and Test with Node.js 18 and ESLint 8 on windows-latest
- GitHub Check: Lint and Test with Node.js 22 and ESLint 8 on windows-latest
- GitHub Check: Lint and Test with Node.js 20 and ESLint 8.56 on windows-latest
🔇 Additional comments (16)
src/rules/no-duplicates.ts (6)
1-1: Update import paths for ESM compatibility.The import statements have been updated to align with ESM standards by:
- Importing
cjsRequirefrom '@pkgr/core' to handle CommonJS modules- Changing from default import to namespace import for semver
- Adding explicit '.js' extensions to local module imports
These changes are necessary for proper ESM module resolution which requires explicit file extensions.
Also applies to: 3-3, 6-7
15-15: Switch to cjsRequire for CommonJS compatibility.Good use of
cjsRequireto load TypeScript package.json in an ESM context, which is necessary since directrequire()calls aren't available in native ESM.
23-26: Convert type alias to exported interface.The type declaration has been upgraded from a non-exported type alias to an exported interface, improving its visibility and making it accessible to other modules. This change follows the pattern seen in other rules and is consistent with good TypeScript practices in an ESM environment.
28-28: Export the MessageId type.Properly exporting the MessageId type enhances its visibility and allows it to be imported by other modules. This follows the pattern established in other rule files like no-amd.ts, no-self-import.ts, etc.
397-403: Convert ModuleMap type alias to exported interface.The ModuleMap type has been properly converted from a type alias to an exported interface, making it consistent with other exported types and allowing for external consumption. This change matches the overall pattern of improving type visibility across the codebase.
405-405: Update to ESM default export syntax.The export statement has been updated from CommonJS-style
export =to ESM-styleexport default, which is required for ESM compatibility. This change ensures the rule can be properly imported in an ESM environment.eslint.config.js (10)
1-2: Good TypeScript integration with@ts-checkStarting the file with TypeScript checking is a great practice, ensuring type safety even in JavaScript configuration files.
3-16: Well-structured ESM imports aligned with migration goalThe ESM import statements properly align with the PR objective of migrating to ECMAScript Modules as the primary module system. The comprehensive set of linting plugins shows good attention to code quality across different aspects (TypeScript, JSON, MDX, etc.).
21-43: Well-structured flat config with appropriate presetsThe ESLint flat config format is used correctly, with a proper layering of configurations. Good job on ordering the configs with the basic ones first and Prettier last to ensure it can override formatting rules from other plugins.
49-54: Proper TypeScript import resolution setupGood configuration of the TypeScript import resolver to work with the project structure. This will ensure imports are correctly resolved for TypeScript files, which is crucial for the ESM migration.
98-109: Effective dog-fooding of the plugin's own rulesGood practice to use the plugin's own rules in its configuration ("dog-fooding"). The configuration for
import-x/no-extraneous-dependencieslooks appropriate, allowing dev dependencies in test files and peer dependencies in the main code.
113-144: Comprehensive TypeScript-specific rulesThe TypeScript-specific rules are well-configured, especially the type import and definition consistency rules that will help maintain code quality during and after the ESM migration.
146-159: Appropriate rule exemptions for test and config filesGood practice to disable stricter dependency rules for test files and configuration files, which often need to import packages that aren't required in production code.
160-165: Proper handling of CommonJS filesGood to see explicit handling of
.cjsand.ctsfiles with Node.js globals, ensuring a smooth transition period where both module systems might coexist.
173-178: Documented rule exception with referenceExcellent practice to include a link to the issue (import-js#655) explaining why the
no-irregular-whitespacerule is disabled for README.md. This helps future maintainers understand the reasoning.
65-65:✅ Verification successful
Verify ESLint version condition logic
The conditional rule for
no-constant-conditionbased on ESLint version seems appropriate, but verify if version 9 is indeed the correct threshold for this change.
🏁 Script executed:
#!/bin/bash # Check ESLint changelog to verify when the no-constant-condition rule behavior changed echo "Checking ESLint version and rule changes" rg -A 3 "no-constant-condition" node_modules/eslint/CHANGELOG.md || echo "No relevant changes found in changelog" # Check actual rule implementation differences between versions if [ -d "node_modules/eslint" ]; then echo "Checking rule implementation in current version" find node_modules/eslint -path "*rules*constant-condition*" -type f | xargs cat else echo "ESLint not installed locally" fiLength of output: 5000
ESLint version threshold validation for
no-constant-condition
Based on our verification:
- The changelog search produced no entries related to changes in the
no-constant-conditionrule.- The current rule implementation in ESLint (as found in the rule source) does not indicate any additional modifications that would affect its behavior relative to ESLint v9.
Given this, using ESLint v9 as the threshold for switching from
'off'to'error'appears appropriate. Please ensure, however, that future ESLint release notes are monitored for any changes in the rule’s behavior that may require an update to this condition.
@coderabbitai Again, run |
JounQin
force-pushed
the
feat/esm_primary
branch
from
d80d534 to
f48530e
Compare
@coderabbitai We support ESM and commonjs at the same time. |
|
Tip For best results, initiate chat on the files or code changes. @JounQin I understand now - you're maintaining compatibility with both ESM and CommonJS module systems simultaneously during this migration. This dual-support approach makes perfect sense given your transition to ESM as primary, and using (・ω・) Understanding your approach now! ✏️ Learnings added
|
After this PR, it should be easier to migrate to
vitest.Summary by CodeRabbit
.jsfile extensions for improved module resolution.cjsRequirefor CommonJS-style imports, improving compatibility with ES module syntax.