fix: respect resolve.conditions, when resolving browser/require field

[sheremet-va]

Description

Conditions for browser/node and require/import are interchangable. If I, as a user, specifically requested to use node condition, I expect it to not use browser condition. The same can be said about require.

https://github.com/lukeed/resolve.exports/blob/587b0ba1adcbef257a108b7c8edb12ce0cb1bfb2/src/index.js#L72

Additional context

---

What is the purpose of this pull request?

• Bug fix
• New Feature
• Documentation update
• Other

Before submitting the PR, please make sure you do the following

• Read the Contributing Guidelines.
• Read the Pull Request Guidelines and follow the Commit Convention.
• Check that there isn't already a PR that solves the problem the same way to avoid creating a duplicate.
• Provide a description in this PR that addresses what the PR is solving, or reference the issue that it solves (e.g. fixes #123).
• Ideally, include relevant tests that fail without this PR but pass with it.

[patak-dev]

Is there a use case for this one? Maybe we should warn here? For targetWeb, we always need browser resolution, no?

[sheremet-va]

Currently the only usage is in Vitest, where part of the codebase is transformed with ssr flag, and part is not. Unfortunately it mixes up resolving, where some packages are resolved with browser condition, and others are with node condition, because resolve.exports always adds one or the other.

We do different transformations for performance reasons. Also, usually, frameworks are transformed without ssr flag (like, Vue), because they might try to inject Node logic, or redirect file to noop, because they expect some code to not be run (like with onMounted in Svelte).

I don't see anything wrong with adding this check here, even if not considering usecases above. Otherwise it creates ambiguity, if user injected 'node' condition (why would it use 'browser'?). There is no way of opting out. Currently, in Vitest injecting node condition helps with the packages that defined node above all other export conditions, but fails otherwise.

Also I don't think we need to come up with another solution for this (like, "web"-like mode, but for...). Vitest has unique requirements where code should be transformed as for the web, but files should be resolved as for node (because we are running code inside Node, and not in a browser, and we prefer its resolution algorithm).

[patak-dev]

Makes sense, more looking at what the linked resolve.exports does.
Shouldn't isRequire already have !conditions.includes('import') into account though? We are forcing it to be true in other places. I'm fine moving forward with this change for now, since as you explained if the user is adding this condition, it doesn't hurt to respect it here.

[sheremet-va]

@antfu can you have a look? 😄