Skip to content
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

[Vite plugin]: assets only imported in resource routes not included in build output #7847

Closed
1 task done
manzano78 opened this issue Oct 31, 2023 · 7 comments
Closed
1 task done

Comments

@manzano78
Copy link
Contributor

What version of Remix are you using?

v0.0.0-nightly-99a8d9c-20231031

Are all your remix dependencies & dev-dependencies using the same version?

  • Yes

Steps to Reproduce

Exactly the same issue than this one with the current compiler : #3414

  1. Configure a project with the new unstable vite plugin as compiler
  2. Create a resource route module which imports an asset as an URL and exposes it via the loader
import stylesheetUrl from './stylesheet.css?url'; // vite syntax

export function loader() {
  return json({ stylesheetUrl });
}

The issue also occurs on normal UI routes when the URL is only used in the loader, server side.

  1. npm run build

Expected Behavior

I would expect the asset to be included in the build output

Actual Behavior

The asset is not included in the build output

@hi-ogawa
Copy link
Contributor

hi-ogawa commented Nov 3, 2023

It seems vite now provides build.ssrEmitAssets option which solved similar issues initially came up on sveltekit:

Further context on sveltekit:

@manzano78
Copy link
Contributor Author

@hi-ogawa, thanks for this information! I've just tried it, indeed it now generates the assets but in the server build folder instead of the public one. Consequently, it's still produces 404s in the browser :-/

@hi-ogawa
Copy link
Contributor

hi-ogawa commented Nov 3, 2023

@manzano78 Thanks for experimenting it. Indeed, just setting the option in the user config alone is not a complete solution.

Looking at svelte's case sveltejs/kit#9073, what they ended up doing is to simply copy over all "server" assets to "client" assets.
It might depend on how you configure remix build directories, but a similar thing could be achieved by just simple script like:

cp -f build/assets/* public/build/assets

then this can be simply chained together in build script:

 "build": "vite build && vite build --ssr && cp -f build/assets/* public/build/assets"

@manzano78
Copy link
Contributor Author

@hi-ogawa thank you very much for your help, I appreciate! This solution seems okay for the production build but I think it can't work in development mode with HMR and HDR, can it?

@hi-ogawa
Copy link
Contributor

hi-ogawa commented Nov 3, 2023

FYI, I'm attempting a fix in #7892, which mostly does the same thing as cp ... but does it inside vite plugin.

This solution seems okay for the production build but I think it can't work in development mode with HMR and HDR, can it?

I don't think this specific issues are relevant for dev since vite serves asset files directly without moving or renaming asset file with hash etc...

But, looking at your case, the usage of ./stylesheet.css?url might have a different issue with vite #7786, so ssrEmitAssets will not probably solve that part of a problem.

@markdalgleish
Copy link
Member

This is fixed by #7892.

Since you're using .css?url imports, you should also be running Vite v5.1.0-beta.0 or later (currently at v5.1.0-beta.6) and setting build.cssMinify to true in your Vite config. This setting will be enabled by default in the next release of the Remix Vite plugin.

@manzano78
Copy link
Contributor Author

@markdalgleish, despite the latest version of Vite (v5.1.1), the latest Remix nightly (v0.0.0-nightly-4111fd1-20240210) and build.cssMinify to true, I can still reproduce this issue. The CSS files which are only referenced server side with .css?url are not copied to the client assets. Should I open a new issue?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants