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.

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

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

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

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

@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!

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?

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.

@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'

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