[RFC] Specify sub directory for all the generated assets for easy deploy and serve

[npup]

TLDR;

My point is that serving the built project (both in prod and dev) could be so much easier in the common case if generated assets were not necessarily put alongside the main index file -- and an option for it could carry its weight.

What am I talking about?

Consider having a src/index.html file, referring css and js files (living anywhere in the src tree).
Without any options used when bundling the resulting assets are generated alongside the index.html in ./dist/ like:

dist/
  index.html
  50c20e2a4174028d1e9d4574129f6104.css
  50c20e2a4174028d1e9d4574129f6104.js

-- and the index.html is rewritten to refer them nicely.

SPA stylee, the dist folder is to be statically served by nginx/equivalent, and for a seamless dev experience I'd like to deploy it as is -- or even build it in place on Heroku or such.

For that, I would love a build option to say "all the generated assets should live in a sub directory by the name of foo". (We already have an output-dir option, which sets the name of the whole build output, and a public-url option, though the latter just affects the referring paths in index.html (in this case) ).

This could the the result of my idea:

dist/
  index.html
  foo/
    50c20e2a4174028d1e9d4574129f6104.css
    50c20e2a4174028d1e9d4574129f6104.js

That way nginx/whatever could happily serve index.html for all requests but foo and under.

An alternative would be

• using the public-url option to have index.html refer assets in foo
• having a post build step to "manually" move asset files to dist/foo

, but this juggling does not work very well in development mode, wanting nginx to serve files in the same manner from the local dist/.

Creating a more elaborate bunch of rules for the file server to have it avoid serving index for any generated asset file is another cumbersome route I'd happily avoid :D .

[davidnagli]

Is this essential to making SPAs? Can we avoid having to add more to our CLI by just letting NGINX handel all of this rather than parcel?

[npup]

@davidnagli
Thanks for chiming in!

An SPA was my initial use case (and used in my example), though I'd like to see it as a generally nice feature just to to be able to say where my generated files shall end up.
If we are talking developer experience, this is really quite helpful (for other post processing too!). Hey, in comparison, the output-diroption does not help as much, but it is still there ;).

As for the SPA case -- leaving the generated structure flat with no options (leaving the web server to handle this) is really not very ergonomic in the general case. Again, makes for a really smooth developer experience, which is something I sensed is a goal of this cool tool.

[davidnagli]

Ya I definetly see where you’re going with this. It seems like a pretty important feature.

How do you think we should implement this?

The whole point of Parcel is that there is no configure file, so we would want to implement it in a way that’s very automatic. I just can’t figure out how to design it in a way that is actually easy and productive for developers.

[mrbar42]

wouldn't nginx's try_files directive solve the problem?

location / {
    try_files $uri /index.html;
}

this will make nginx to try and serve a file under the request uri and otherwise fallback to index.html

it might be worth creating a guide for such case for common web servers.

[npup]

@mrbar42 that's a nice one, but nginx and/or SPA are not the only reasons to need the generated files/assets to be easily distinguished in the general case -- be it in the form of naming a directory for them or having the files prefixed or whatever.

@davidnagli What would the major problem be with a cli option like the existing public-url and output-dir, that makes the generated files land (and be referenced) in a directory with a certain name?