Port enhance import extension enforcement with autofix support

[lucgagan]

Just think this is a great PR that's been sitting idle on the parent GitHub repo:

• feat(extensions): enhance import extension enforcement with autofix support import-js/eslint-plugin-import#3177
• Feature request: import/extensions autofix import-js/eslint-plugin-import#1749

[petercat-assistant]

It seems like you're interested in a pull request and an issue from the eslint-plugin-import repository that you believe would be beneficial if ported to the un-ts/eslint-plugin-import-x repository. The pull request you mentioned is aimed at enhancing import extension enforcement with autofix support.

If you would like to discuss this further or need assistance with a specific aspect of this task, feel free to let me know! If you're considering creating a similar feature or issue in the un-ts/eslint-plugin-import-x repository, I can help guide you through the process or provide more information.

[JounQin]

@lucgagan Feel free to PR to contribute!

[lucgagan]

I will wait to see if the original author wants to take the credit, but if not, I am happy to step in

[stephenjason89]

Hi @lucgagan, @JounQin,

Thank you for highlighting the interest in porting the autofix support for the import/extensions rule. I appreciate the opportunity to contribute to eslint-plugin-import-x.

I’ve reviewed the current implementation of the import/extensions rule in eslint-plugin-import-x and noted the differences from the original eslint-plugin-import. Given these differences, I plan to adapt my previous work to align with the structure and conventions of this repository.

I’ll proceed with:
• Implementing the autofix functionality for the import/extensions rule.
• Writing comprehensive tests to ensure reliability.
• Updating documentation to reflect the changes.

I’ll aim to submit a pull request next week. If there are any specific guidelines or considerations I should be aware of while working on this, please let me know.

[JounQin]

@stephenjason89 Thanks for your efforts first! What's the differencea you mean? The implementation should be same except TypeScript rewrite.

[stephenjason89]

@stephenjason89 Thanks for your efforts first! What's the differencea you mean? The implementation should be same except TypeScript rewrite.

Hey, thanks for the quick response! 😊

You’re right that the core rule logic stays the same—the differences I’m referring to are the little bells and whistles around it:

• pathGroupOverrides support is already in eslint-plugin-import-x, and I’ll be sure to respect it in my autofix work.
• I’m adding autofix support so that safe fixes (adding or stripping extensions) happen automatically. By default I’ll enable fixes like most ESLint rules, but if I hit any test regressions I’ll drop it behind a fix: true flag.

While these changes are fairly minimal, I’ll keep an eye on test coverage and consider whether making autofix opt-in makes more sense. Let me know if you’d rather start with it behind a flag!

[JounQin]

pathGroupOverrides is a good example

There could be a chance we didn't port upstream changes yet, if that's not blocking you too much, maybe port that part altogether could be considered. I'm thinking to have same defaults as upstream except there are great reasons not, so that the users can migrate from import to import-x smoothly.

[stephenjason89]

pathGroupOverrides is a good example

I'm thinking to have same defaults as upstream except there are great reasons not, so that the users can migrate from import to import-x smoothly.

Thanks! I actually agree — we shouldn't have the same defaults in all cases, but matching upstream is essential for smoother migration.

That said, I do have some minor preferences on adjusting the defaults. The original plugin defaults to "never", which can lead to unexpected behavior. For example:

"import/extensions": ["error", {
  "pattern": {
    "js": "always"
  }
}]

In this case, all other extensions (like ts, vue, etc.) implicitly fall back to "never", even though they’re not defined. I personally believe that if an extension isn’t explicitly listed, the rule shouldn't apply to it — users should opt in clearly.

I mentioned this in the original repo for context:
original comment

Happy to help port this logic over to import-x if it makes sense to align on a default that’s both compatible and developer-friendly.

[JounQin]

Happy to help port this logic over to import-x if it makes sense to align on a default that’s both compatible and developer-friendly.

I think that could be included in another PR? It seems a BREAKING CHANGE to me, maybe worth to be considered in next major #235.

cc @SukkaW

[SukkaW]

I think that could be included in another PR? It seems a BREAKING CHANGE to me, maybe worth to be considered in next major #235.

Hmmm, I agree with the process, except the "adjustments". I do understand the frustration of not explicitly defined extensions falling back to undocumented default. But what if instead we do this:

interface RuleOptions {
  pattern: 'always' | 'never' | Record<string, 'always' | 'never'>
}

{ pattern: 'always' } then applies to every file.

[stephenjason89]

Thanks for the discussion!

With the new union type, you can restore the old fallback in a self-documenting way:

// Legacy behavior: every extension → 'never'
{ pattern: 'never' }

And when you want opt-in per extension, simply list only the ones you care about:

// Only .js files get 'always'; all others are ignored
{ pattern: { js: 'always' } }

This makes the intent crystal-clear and removes any hidden defaults.

What does everyone think?

[SukkaW]

Thanks for the discussion!

With the new union type, you can restore the old fallback in a self-documenting way:

// Legacy behavior: every extension → 'never'
{ pattern: 'never' }
And when you want opt-in per extension, simply list only the ones you care about:

// Only .js files get 'always'; all others are ignored
{ pattern: { js: 'always' } }
This makes the intent crystal-clear and removes any hidden defaults.

What does everyone think?

Also no breaking change, since it is a new option without changing existing behavior!

[JounQin]

And when you want opt-in per extension, simply list only the ones you care about:

Doesn't it change the upstream's behavior on object options?

[stephenjason89]

And when you want opt-in per extension, simply list only the ones you care about:

Doesn't it change the upstream's behavior on object options?

It actually does a bit but can easily restore the old behavior by defining

{ pattern: 'never' }

But for specific file extensions then yes behavior will be changed a bit if my understanding was correct.

Imagine having

{ pattern: { js: 'always' } }

With the old behavior, js will have always ext. Other types not defined, like ts for example, will have never by default.

With the new behavior, I was personally aiming for

All other extensions not defined will just be ignored. Unless a rule applies to them.

[JounQin]

All other extensions not defined will just be ignored. Unless a rule applies to them.

I understand and that's exactly I want to avoid in current port, we can change the behavior in the next major.