extensions rule autofix requires strange configuration options to work

[lnhrdt]

First of all, thank you @stephenjason89 and @JounQin for getting the extensions autofix contribution merged in #327. I’ve been eager to use Stephen’s PR since I first saw the attempt in import-js/eslint-plugin-import#1749.

I've been finding it difficult to configure the extensions rule autofix to work. I'm suspicious that the behavior I'm seeing is unintentional and might be a bug.

What I've found is that the extensions rule autofix only works when both of the following are true:

1. a fix: true option is set
2. a pattern: {} option is set, even if empty (the contents of the pattern object do not seem to matter)

Steps to Reproduce

In my testing, these do not enable autofix:

'import-x/extensions': ['warn', 'never'],
'import-x/extensions': ['warn', 'never', { fix: true }],
'import-x/extensions': ['warn', 'never', { pattern: {} }],

But this does enable autofix:

'import-x/extensions': ['warn', 'never', { fix: true, pattern: {} }],

Questions

1. Is autofix intended to be opt-in via fix: true? I saw this comment suggesting it might be, but this isn’t documented, and no other rules in this project use a fix option. I was only able to discover the fix: boolean option by looking through the PR history and source code.
2. Is requiring a pattern object to enable autofix intentional? It seems like an oversight, especially since an empty object works.

Thanks again for all the work on this plugin.

[JounQin]

Could you provide a GitHub repo as a minimal but runnable reproduction instead?

[lnhrdt]

Thanks for the reply @JounQin. I initially thought the written steps would be sufficient, but to make things clearer, I've put together a runnable reproduction: https://github.com/lnhrdt/un-ts-eslint-plugin-import-x-issue-391

Let me know if anything's still unclear or if you run into any issues reproducing the behavior.

[JounQin]

Thanks, I'll take a look when I'm free enough.

[lnhrdt]

Thanks again for the quick reply @JounQin. I went ahead and opened #393 to add failing tests that demonstrate the issue directly in the test suite.

I’d still recommend reviewing the standalone reproduction first, as it’s easier to observe the core problem in isolation:
https://github.com/lnhrdt/un-ts-eslint-plugin-import-x-issue-391