Fix: add universal export to root

[SimenB]

Jest doesn't support package exports (yet), so if you currently try to load eslint from within Jest (such as for running ruleTester) it fails to resolve unless the user adds some config like

{
  "jest": {
    "moduleNameMapper": {
      "@eslint/eslintrc/universal": "@eslint/eslintrc/dist/eslintrc-universal.cjs"
    }
  }
}

It would be nice if it just worked 🙂

I very much understand if you don't wanna add this hack for Jest's lack of support for package exports, but since it's not a big burden I have some hope 👍

[linux-foundation-easycla]

The committers are authorized under a signed CLA.

• ✅ Simen Bekkhus (c2b8e32, 2caa874)

[eslint-github-bot]

Hi @SimenB!, thanks for the Pull Request

The pull request title isn't properly formatted. We ask that you update the message to match this format, as we use it to generate changelogs and automate releases.

• The commit message tag must be one of the following:

  The Tag is one of the following:

  • Fix - for a bug fix.
  • Update - either for a backwards-compatible enhancement or for a rule change that adds reported problems.
  • New - implements a new feature.
  • Breaking - for a backwards-incompatible enhancement or feature.
  • Docs - changes to documentation only.
  • Build - changes to build process only.
  • Upgrade - for a dependency upgrade.
  • Chore - for anything that isn't user-facing (for example, refactoring, adding tests, etc.).

  You can use the labels of the issue you are working on to determine the best tag.

• There should be a space following the initial tag and colon, for example 'New: Message'.

• The first letter of the tag should be in uppercase

Read more about contributing to ESLint here

[nzakas]

This was brought up during the beta period so we assumed Jest would resolve the issue before the final release came out. What’s your timeline for the fix?

[ljharb]

Unfortunately there’s no timeline yet for resolve, which is what jest uses currently - that doesn’t preclude jest fixing it faster.

I’ve been trying to find the time for it for awhile :-/ node also keeps altering the exports field semantics, which makes it harder.

[btmills]

Espree, the default parser, also uses package exports now. If we include this workaround, would we need to do the same thing in that project too?

[SimenB]

This was brought up during the beta period so we assumed Jest would resolve the issue before the final release came out. What’s your timeline for the fix?

As Jordan mentions, Jest uses resolve which currently doesn't support it. I might be able to land a workaround for the default export (i.e. ., so not even applicable to this specific case) in jestjs/jest#11919, but that's a bit hacky and as I mention there I'm not a huge fan of the default semantics of resolve.exports so even that is sorta in in limbo atm. So I don't really have a timeline here, unfortunately. 🙁

Espree, the default parser, also uses package exports now. If we include this workaround, would we need to do the same thing in that project too?

No, since espree only uses exports to do conditionals on the entry point plus package.json, and it still specifies a main entry which is CJS, that still works without an issue. If you were to add some other export (like /universal here) it would fail, but the way espree is now is not an issue due to the presence of the main field 🙂

---

If consumers of Jest wanna use native ESM this would fall apart of course, but due to the APIs jest use in Node still being flagged (and probably will be for some time) I assume most people (by far) still use CJS (or TS/Babel compiled ESM)

[SimenB]

I added a comment explaining some of this in the file, which might include a non-starter - you use type: "module" but this is a .js file so technically cannot use require in it at all 😅 As mentioned there, Jest doesn't support type field in package.json outside of ESM mode (https://github.com/facebook/jest/blob/64de4d7361367fd711a231d25c37f3be89564264/packages/jest-resolve/src/shouldLoadAsEsm.ts#L31-L33) which is a bug I should probably fix, at which point even this workaround would stop working. But this would still work for other versions of Jest (if I can even fix it without proper exports support, at which point the workaround will be moot anyways)

[SimenB]

FWIW I opened browserify/resolve#253 which might unblock Jest, but I'd still love to see this workaround land for all older versions of Jest anyways 🙂

[btmills]

I’m not thrilled about including a workaround like this because we won’t be able to remove it unless we include “drop support for Jest <x.y.z” as a breaking change. It’s unusual that Jest would be part of this package’s compatibility matrix. However, we’re trying to migrate to a new config system, so we’ll eventually stop working on this package, reducing the impact of this workaround being effectively permanent. Given this is the only way for all existing Jest versions to work with ESLint v8, and there’s no timeline for support without this workaround in future versions of Jest, I think it’s best for the community that we do this.

[nzakas]

Agreed

[SimenB]

Thank you! ❤️

[SimenB]

Circling back to this, Jest 28 has full support (afaik) of exports. Currently in alpha releases, but I just need to write the blog post and we're ready for a stable release. Hopefully done this weekend