Unnecessary checks for config name in extend option of .eslintrc

[rmbaad]

Hi, there! Thank you for this great tool.
I faced the problem while creating a new ESLint config as a package to extend from it and want to ask to discuss about it.

The version of ESLint you are using.
7.7.0

The problem you want to solve.
Give more freedom to name ESLint configs

Your take on the correct solution to problem.
Currently, we have strong rules to name ESLint configs, e.g. eslint-config-myconfig, or @namespace/eslint-config-myconfig.
Please tell me, is this really justified? Yes, we can extend configs from the short name, like "extends": 'myconfig', but in the case with the name which contains namespace, is it really necessary to follow these rules?
Some companies have rules for package naming in their own namespaces, and if you want to name your config e.g. as myteam-eslint-config it doesn't work to extend from. We just will get an error like ESLint couldn't find the config "@namespace/myteam-eslint-config" to extend from, but it's the full name of package and it seems like there are no problems to find it.
Perhaps we can rethink the approach to name configs with names which contains namespace and remove checks of this rule.
Thank you!

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

[mdjermanovic]

Hi @rmbaad, thanks for the issue!

We are working on the new simple config system (eslint/rfcs#9) where the configs to extend from can be loaded from the configuration file instead of specified, so you'll be able to require a shared config with any name. You can follow the implementation progress here: #13481.

In the meantime, we have decided to not make further changes to the current config system.

While at the current config system, extends value can be an absolute or relative path, so perhaps you could do something like this in a .js config:

module.exports = {
  extends: [require.resolve("@namespace/myteam-eslint-config")]
};

[rmbaad]

Thank you, @mdjermanovic! This is a good solution.