fix: add languageOptions to ChildContext

[kosmotema]

Currently the plugin loses languageOptions when creating a child context (when using a flat config). This causes errors when plugin tries to use the default parser, i.e. languageOptions.parser

I've also created a reproduction for this bug

[changeset-bot]

🦋 Changeset detected

Latest commit: 4ece153

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
eslint-plugin-import-x	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[codesandbox-ci]

This pull request is automatically built and testable in CodeSandbox.

To see build info of the built libraries, click here or the icon next to each commit SHA.

[kosmotema]

I extracted the logic of creating the context cache key into a separate function, and also made a function for obtaining a hash for options with its caching (since adding 2 more global variables for parser.meta doesn't seem so good)

[n0099]

This pr seems similar with import-js#2829 but with additional cache and both should fix Parse errors in imported module '': parserPath or languageOptions.parser is required!: import-js#2556 (comment)

[kosmotema]

Refactored a bit context hashing:

• now all cached properties are declared when the object is created
• also I decided to use dequal instead of JSON.stringify and store the actual values in the cache instead of their json

A little more on the second point:
I've noticed that settings and languageOptions (for flat config) often doesn't change when childContext is called again (i.e. they're referentially equal). So it seems that jsoning the values each time is often unnecessary and inefficient, and we can just use deep equal approach for comparing (which will handle the referentially equality case faster)

[SukkaW]

@kosmotema I noticed that a few tests were not passed and CI failed. I am blocking the PR for now.

[kosmotema]

Found and fixed the bug that causes this test to fail. For some reason I thought before that parserPath and languageOptions are exclusive (i.e. if there is languageOptions, parserPath will be nullish). It turned out that it is not quite so :(
Now to get a real parser, an algorithm similar to getParser is used

Also decided to switch from hashing approach to the versioning one. Since we already use deep equality to compare context options, it seems that hashing is not really necessary. So we can simply increment the version when some options change, and return that version as a string

[SukkaW]

Since we already use deep equality to compare context options, it seems that hashing is not really necessary. So we can simply increment the version when some options change, and return that version as a string

This reminds me of a package https://www.npmjs.com/package/stable-hash that does exactly that, IMHO we can use this package instead of self implementing this!