fix: Avoid dirname for built-in configs.

[daidodo]

Load eslint:recommended and eslint:all configs via import instead file paths.

Fixes: #15575

Prerequisites checklist

• I have read the contributing guidelines.

What is the purpose of this pull request? (put an "X" next to an item)

• Documentation update
• Bug fix (template)
• New rule (template)
• Changes an existing rule (template)
• Add autofix to a rule
• Add a CLI option
• Add something to the core
• Other, please explain: Avoid using __dirname for built-in configs, i.e. eslint:recommended and eslint:all.

What changes did you make? (Give an overview)

I made changes to cli-engine.js and file-enumerator.js to pass in callbacks for getting built-in configs instead of file paths.

Is there anything you'd like reviewers to focus on?

The main changes are in @eslint/eslintrc (PR).
It should be merged and released first before changes here can be applied.

[nzakas]

Can you add some tests for this?

[daidodo]

Could you tell me what tests you are expecting? I thought there were no API changes so existing tests should be enough.
Please also note that the tests failed because eslint/eslintrc#71 hasn't been released.
Thanks!

[mdjermanovic]

We recently added some tests that would fail if this doesn't work at all: bfaa548

Maybe we could add another test in tests/lib/cli-engine/cli-engine.js to check entire configurations, and also make sure that we won't accidentally revert to passing string paths:

it("should pass functions that load built-in configs to CascadingConfigArrayFactory", () => {

    let constructorArgs;

    const eslintrc = require("@eslint/eslintrc");
    const { CLIEngine } = proxyquire("../../../lib/cli-engine/cli-engine", {
        "@eslint/eslintrc": {
            ...eslintrc,
            Legacy: {
                ...eslintrc.Legacy,
                CascadingConfigArrayFactory: class extends CascadingConfigArrayFactory {
                    constructor(...args) {
                        constructorArgs = args;
                        super(...args);
                    }
                }
            }
        }
    });

    // eslint-disable-next-line no-new -- Testing side effects
    new CLIEngine();

    const [options] = constructorArgs;

    assert.strictEqual(typeof options.eslintRecommendedPath, "undefined");
    assert.strictEqual(typeof options.getEslintRecommendedConfig, "function");
    assert.deepStrictEqual(options.getEslintRecommendedConfig(), require("../../../conf/eslint-recommended"));
    assert.strictEqual(typeof options.eslintAllPath, "undefined");
    assert.strictEqual(typeof options.getEslintAllConfig, "function");
    assert.deepStrictEqual(options.getEslintAllConfig(), require("../../../conf/eslint-all"));

});

@nzakas did you mean something like this?

[nzakas]

I’d much prefer a simpler test where we check configs with eslint:recommended and eslint:all produce the desired results.

[mdjermanovic]

I’d much prefer a simpler test where we check configs with eslint:recommended and eslint:all produce the desired results

There are such tests for the ESLint class with eslint:recommended and eslint:all configs here.

[nzakas]

Ah good call. In that case I think we are good. 👍

I’m assuming the lint error will resolve when eslintrc is upgraded.

[mdjermanovic]

I'll close-reopen to run checks with these changes on top of the latest main.

[mdjermanovic]

LGTM, thanks for contributing!