fix: parse env options from comments (fix #1962)

[nickmccurdy]

No description provided.

[nickmccurdy]

I seem to have fixed the bug, but I'm not sure if I have the environment option merging right, and things could probably be cleaner and faster in the long run (see #1987).

[sheremet-va]

What about this case?

// file1.ts
// @vitest-environment custom
// @vitest-environment-options {"option1":1,"option2":2}

// file2.ts
// @vitest-environment custom
// @vitest-environment-options {"option2":2,"option1":1}

These files should run in the same environment, because they have the same values.

[nickmccurdy]

Personally I'm not sure that's beneficial enough to be worth the downsides. We would have to make the equality logic much more complex. Also from what I understand, the JSON and ECMAScript spec do not specify whether parsers need to be ordered, so we would need to hard code different logic for JavaScript runtimes and environments. Even if we only supported V8, we would have to either ban numerical keys (technically a breaking change since custom environments can have any keys), or introduce undefined runtime behavior (possibly a breaking change).

If you wanted to ensure better performance as a user, you could simply sort your keys with a linter. Worst case, we get an O(n) performance in exchange for respecting the ECMAScript spec, which I think is worth it.

Would something break if we made the wrong assumption about option equality for grouping envs? If not, then this is just a performance issue and maybe that argument doesn't hold much weight. However, in that case I think adding too much time complexity for edge cases like this could make tests slower than if they had some extra env instances. Also JSON parsing is synchronous, but we already parallelize envs.

[sheremet-va]

Also from what I understand, the JSON and ECMAScript spec do not specify whether parsers need to be ordered, so we would need to hard code different logic for JavaScript runtimes and environments.

I think you overcomplicate things here, I'm sure we can create a string key that doesn't depend on key order. Sorting keys seems like an obvious solution.

If you wanted to ensure better performance as a user, you could simply sort your keys with a linter.

I don't think you can store them with linter in our docblock?

Would something break if we made the wrong assumption about option equality for grouping envs?

Most things that expect single JSOM instance will break, because we don't clear ESM cache in --no-threads: Vue, for example, stores "document" globally on import, so next tests with different "options" will fail, because global "document" will be different. This is actually why we have grouping.

I am sure this usecase will emerge, if people will use @vitet-environment-options.

[nickmccurdy]

Also from what I understand, the JSON and ECMAScript spec do not specify whether parsers need to be ordered, so we would need to hard code different logic for JavaScript runtimes and environments.

I think you overcomplicate things here, I'm sure we can create a string key that doesn't depend on key order. Sorting keys seems like an obvious solution.

That sounds like a good place to start, but I still feel like that's a lot of time complexity. I'll try some benchmarks.

[sheremet-va]

Let's merge it now and see, if the order is really a problem later.