-
-
Notifications
You must be signed in to change notification settings - Fork 5.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix: browser resolution in webworkers #3121
fix: browser resolution in webworkers #3121
Conversation
@patak-js This just hardly remembered me to this commit from me: mib200/vue-gtm@01f3651#diff-57716bc53661ccdb4571d571f1a5493294848965ae6068dbb3d9a1167d2cc1a6R59 There were some folks that had e.g. issues with But I will approve it now, because if my proposal is helpful, we can implement it in another PR anyway |
I think we should provide a configuration point if it is not possible to get this info out of the box. We may need it later, but let's grow the API surface when we get the use cases. |
@patak-js Thanks so much for this! I've tested with Vite 2.2.1 and it still bundles browser cross-fetch for SSR build. I guess some of the merged PRs are still not released? I'll try to checkout this PR and test it locally today but basically, if that's the behavior then it should work well :) Related to this, do you know if there's an equivalent of Rollup's NodeResolve |
Yes, #3039 has not yet been merged. Thanks for trying out this branch, I'll wait to merge it. About |
@patak-js Ah I see, thanks for the clarification! In that case this shouldn't be a problem at all. Right now Vitedge uses Node during development. It's only at build time where I need to make sure that browser-entry is used. Since -- So I've tested this PR and it looks good. As I said, I just need to make sure Thanks! |
@frandiox check out the definition for targetBrowser here. You shouldn't need to set |
@patak-js The thing is that I use Node.js to build and bundle for webworker, so this is always going to detect Node. That's why I asked if this was a flag that can be set manually. I don't currently have any way to test this running in an actual web worker before building for it :/ Therefore, I need |
I am closing this PR, at least for the moment, we can assume that we are always in Node when running the plugins in ssr mode. We discussed with @frandiox and what is needed is a So, #2996 and #3039 didn't introduce a regression for Node. These PRs should count as a fix, they break plugins that assumed browser resolution in ssr (like vitedge) but that was a bug. |
Description
#2996 and #3039 reworked the package resolution to ignore the
browser
field if the plugin is running in ssr mode.See @frandiox comment, if the target is webworker (ie cloudflare workers) then the
browser
field should be respected even in ssr mode.This PR adds a
targetBrowser
param to the resolve methods instead of the previousssr
one. I think thattargetBrowser
is better here thantargetNode
to avoid the need to negate it when using it.isNode
is using the same function from https://github.com/iliakan/detect-node, included in the code to avoid an extra dependency. I don't know if this the most robust way to detect that we are in node and not in a webworker. @frandiox could you check that vite-edge works correctly after this PR (using a dependency that has the browser field, like websocket #2995 or cross-fetch #3036)This is a regression because #2996 was already included in v2.2.0, #3039 has not yet been released.
What is the purpose of this pull request?
Before submitting the PR, please make sure you do the following
fixes #123
).