[vite-plugin]: fix applications not being able to import assets from dependencies

[dario-piotrowicz]

Fixes #8664
Fixes remix-run/react-router-templates#104

This PR fixes server side code being run using our vite pluging being unable to import assets from dependencies
(e.g. import stylesheet from "@shopify/polaris/build/esm/styles.css?url"; in react ssr code)

---

• Tests
  • TODO (before merge)
  • Tests included
  • Tests not necessary because:
• Wrangler E2E Tests CI Job required? (Use "e2e" label or ask maintainer to run separately)
  • I don't know
  • Required
  • Not required because: unrelated to wrangler
• Public documentation
  • TODO (before merge)
  • Cloudflare docs PR(s):
  • Documentation not necessary because: bugfix
• Wrangler V3 Backport
  • TODO (before merge)
  • Wrangler PR:
  • Not necessary because: not a Wrangler change

[changeset-bot]

🦋 Changeset detected

Latest commit: 198b521

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
@cloudflare/vite-plugin	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[github-actions]

A wrangler prerelease is available for testing. You can install this latest build in your project with:

npm install --save-dev https://prerelease-registry.devprod.cloudflare.dev/workers-sdk/runs/14196721824/npm-package-wrangler-8672

You can reference the automatically updated head of this PR with:

npm install --save-dev https://prerelease-registry.devprod.cloudflare.dev/workers-sdk/prs/8672/npm-package-wrangler-8672

Or you can use npx with this latest build directly:

npx https://prerelease-registry.devprod.cloudflare.dev/workers-sdk/runs/14196721824/npm-package-wrangler-8672 dev path/to/script.js

Additional artifacts:

cloudflare-workers-bindings-extension:

wget https://prerelease-registry.devprod.cloudflare.dev/workers-sdk/runs/14196721824/npm-package-cloudflare-workers-bindings-extension-8672 -O ./cloudflare-workers-bindings-extension.0.0.0-vb7a0a645e.vsix && code --install-extension ./cloudflare-workers-bindings-extension.0.0.0-vb7a0a645e.vsix

create-cloudflare:

npx https://prerelease-registry.devprod.cloudflare.dev/workers-sdk/runs/14196721824/npm-package-create-cloudflare-8672 --no-auto-update

@cloudflare/kv-asset-handler:

npm install https://prerelease-registry.devprod.cloudflare.dev/workers-sdk/runs/14196721824/npm-package-cloudflare-kv-asset-handler-8672

miniflare:

npm install https://prerelease-registry.devprod.cloudflare.dev/workers-sdk/runs/14196721824/npm-package-miniflare-8672

@cloudflare/pages-shared:

npm install https://prerelease-registry.devprod.cloudflare.dev/workers-sdk/runs/14196721824/npm-package-cloudflare-pages-shared-8672

@cloudflare/unenv-preset:

npm install https://prerelease-registry.devprod.cloudflare.dev/workers-sdk/runs/14196721824/npm-package-cloudflare-unenv-preset-8672

@cloudflare/vite-plugin:

npm install https://prerelease-registry.devprod.cloudflare.dev/workers-sdk/runs/14196721824/npm-package-cloudflare-vite-plugin-8672

@cloudflare/vitest-pool-workers:

npm install https://prerelease-registry.devprod.cloudflare.dev/workers-sdk/runs/14196721824/npm-package-cloudflare-vitest-pool-workers-8672

@cloudflare/workers-editor-shared:

npm install https://prerelease-registry.devprod.cloudflare.dev/workers-sdk/runs/14196721824/npm-package-cloudflare-workers-editor-shared-8672

@cloudflare/workers-shared:

npm install https://prerelease-registry.devprod.cloudflare.dev/workers-sdk/runs/14196721824/npm-package-cloudflare-workers-shared-8672

@cloudflare/workflows-shared:

npm install https://prerelease-registry.devprod.cloudflare.dev/workers-sdk/runs/14196721824/npm-package-cloudflare-workflows-shared-8672

Note that these links will no longer work once the GitHub Actions artifact expires.

---

wrangler@4.6.0 includes the following runtime dependencies:

Package	Constraint	Resolved
miniflare	workspace:*	4.20250321.1
workerd	1.20250321.0	1.20250321.0
workerd --version	1.20250321.0	2025-03-21

Please ensure constraints are pinned, and miniflare/workerd minor versions match.

[jamesopstad]

As part of this PR, should we also error/warn in configResolved if the user has optimizeDeps.exclude or resolve.external set for a Worker environment?

[dario-piotrowicz]

As part of this PR, should we also error/warn in configResolved if the user has optimizeDeps.exclude or resolve.external set for a Worker environment?

I'm totally happy to implement that too, but I don't think it needs to be part of this PR? (my personal preference is to keep PRs small and scoped so that they are easier to write, review and look up in the future)

[jamesopstad]

As part of this PR, should we also error/warn in configResolved if the user has optimizeDeps.exclude or resolve.external set for a Worker environment?

I'm totally happy to implement that too, but I don't think it needs to be part of this PR? (my personal preference is to keep PRs small and scoped so that they are easier to write, review and look up in the future)

Sure. I mentioned it now because I kind of feel that runInlinedModule and runExternalModule are the wrong place to be implementing these checks. An alternative would be to remove these, error if the resolved config is not compatible with our architecture and let any other errors propagate as normal.

[dario-piotrowicz]

As part of this PR, should we also error/warn in configResolved if the user has optimizeDeps.exclude or resolve.external set for a Worker environment?

I'm totally happy to implement that too, but I don't think it needs to be part of this PR? (my personal preference is to keep PRs small and scoped so that they are easier to write, review and look up in the future)

Sure. I mentioned it now because I kind of feel that runInlinedModule and runExternalModule are the wrong place to be implementing these checks. An alternative would be to remove these, error if the resolved config is not compatible with our architecture and let any other errors propagate as normal.

I see, but I think that we should have both checks, the ones in runInlinedModule and runExternalModule as the last line of defence in case something slipped through (e.g. the user has some hacky dynamic import of something that bypass correct configs) and also the config validation checks (to prevent these type of issues in the first place).

(basically the way I see it is that the ones in the module runner are the "real" checks while other checks would be more for DX purposes than anything else)

do you think this would be overkill?

[jamesopstad]

I see, but I think that we should have both checks, the ones in runInlinedModule and runExternalModule as the last line of defence in case something slipped through (e.g. the user has some hacky dynamic import of something that bypass correct configs) and also the config validation checks (to prevent these type of issues in the first place).

(basically the way I see it is that the ones in the module runner are the "real" checks while other checks would be more for DX purposes than anything else)

do you think this would be overkill?

I think we should go with the simplest solution and error as early as possible. That's why I prefer my suggestion of validating the resolved config. I feel the logic in runInlinedModule and runExternalModule is too tied to implementation details. If, however, you can reproduce a scenario where errors still occur here without optimizeDeps.exclude or resolve.external set then that would be justification for having more defensive logic at this level.

[dario-piotrowicz]

I think we should go with the simplest solution and error as early as possible. That's why I prefer my suggestion of validating the resolved config. I feel the logic in runInlinedModule and runExternalModule is too tied to implementation details. If, however, you can reproduce a scenario where errors still occur here without optimizeDeps.exclude or resolve.external set then that would be justification for having more defensive logic at this level.

I'm happy to go with your solution and change it if/when needed 👍

[dario-piotrowicz]

Note, I was working an adding an e2e test to make sure the validation takes place, but the e2es seem not to currently fully work as intended, changes in #8688 should fix them, so I can add those after that PR is merged (or do it in a followup PR)

[jamesopstad]

Looks great! Just a few minor comments.

I did also wonder if we should validate resolve.noExternal to check it's always true? We may also want to check that optimizeDeps.noDiscovery is false but we can't do that until this PR is released - remix-run/react-router#13317. We could add both of these together in a future PR if you prefer.

[petebacondarwin]

In general I am keen on a little more context in changesets.
This is what will appear in the changelog and the reader will use it to determine if they should update to this version and/or what effect it will have on their project.

[petebacondarwin]

In particular I think we should say that we now error if the user has invalid config, right?

[dario-piotrowicz]

yes that's a good callout, I wrote this changeset when I made my initial change (which didn't actually change how we validated things) but forgot to update it, I will do that now thanks 🙂