fix(ssr): skip resolving browser field for SSR build

[underfin]

fix: #3036

Description

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.

[stupidawesome]

I believe that this line causes the entry point to become cached, so if the client bundle runs before the SSR bundle, the SSR bundle will re-use the client bundle entry point for a dependency it has seen before, which will always be a browser entry point.

See @stupidawesome comment

[patak-dev]

@stupidawesome good catch. @underfin looks like there is a package data cache that may need to be different for ssr.

[stupidawesome]

I pushed a fix so that the package cache is cleared each time the resolve plugin is resolved. Please check here: stupidawesome@1e9143c

[underfin]

@patak-js @stupidawesome Thanks for your reviewer. Yep, here also need cache for ssr.

[Shinigami92]

Is it easy to swap tryIndex and ssr parameters? If so, this could be a bit more natural.

[frandiox]

@patak-js @underfin Hi! I'm a bit late, just saw the link on Discord. I just wanted to ask, would this affect browser-like environments such as Cloudflare Workers? Or is it still configurable?

As a reference, Webpack resolves ['browser', 'module', 'main'], in order, when the target is webworker.
Thanks!

[patak-dev]

Thanks for the heads up @frandiox, this merged PR would also be affected no? #2996
This is already in v2.2, so that would count as a regression for webworkers. Maybe you could create an issue to properly track this if that is the case

@underfin maybe we should use a "resolveBrowserField" (or better name) instead of "ssr" for the logic that was added to this PR?

[patak-dev]

This PR is correct, as we can assume that we are in Node when doing ssr. The issue with webworkers is not really a regression since they were depending on a bug of Vite. We discussed that it would be good to add a target: 'webworker' as a feature to properly support running the ssr build on the edge.

[zhangyuang]

@underfin @patak-js Why there only tryIndex when no exports field 🤔? It will be error in below code

// error
import Button from 'vant/lib/button'
// succeed
import Button from 'vant/lib/button/index.js'

[patak-dev]

@zhangyuang would you open an issue with a minimal repro and linking to this PR so we can properly track this problem?