Allow extending from arbitrarily named scoped package

[samsch]

The version of ESLint you are using.
7.12.0 is current latest

The problem you want to solve.

I want to extend from a scoped npm package which doesn't have eslint-config as a prefix.

module.exports = {
    extends: '@example/myconfig',
};

Your take on the correct solution to problem.

I'm not sure there's more to describe here without going into implementation.

Are you willing to submit a pull request to implement this change?

At the moment, I can't commit to doing this, no.

[samsch]

Originally I only found #9868 when looking for existing issues, but doing some extra searching, I also found: #9188 #10202 and I think there are some others.

It seems there's community interest in having this change, but pushback from maintainers.

In my case, I attempted to setup the package before finding this rule, and the error output was not helpful:

<project-dir>$ npx eslint index.js

Oops! Something went wrong! :(

ESLint: 7.12.0

ESLint couldn't find the config "@samsch/eslint-default" to extend from. Please check that the name of the config is correct.

The config "@samsch/eslint-default" was referenced from the config file in "<project-dir>/.eslintrc.js".

If you still have problems, please stop by https://eslint.org/chat/help to chat with the team.

If maintainers are against this change, then maybe we could at least have it detect when a package with the given name exists to display a more useful error pointing out the naming requirement.

[mdjermanovic]

Hi @samsch, thanks for the issue!

The extends property value can be an absolute path, so this should work:

module.exports = {
    extends: require.resolve('@example/myconfig')
};

We are also working on the new simple config system (per eslint/rfcs#9) where the configs to extend from should be loaded from the config file instead of specified by name, which means there will be no restrictions or assumptions about the module name. You can follow the progress here: #13481.

[samsch]

Great to hear! Thanks for the links, I think the eventual changes there cover solving this issue, so I'll close out.