-
-
Notifications
You must be signed in to change notification settings - Fork 2.3k
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
[RFC] File naming strategy #872
Comments
I think its a great strategy, though I'd like a CLI option for not putting the assets in a subfolder! Is |
I recommend not making up a unique name for the I'd just prepend an underscore or two, just to lessen the likelihood of name clashes by departing from nice human names: |
I think the strategy looks good. As for the |
Why not just let it default to |
+1
A sensible default and a sensible option sounds great to me too.
2018-02-21 14:49 GMT+01:00 Ben Hutton <[email protected]>:
… Why not just let it default to assets and be overridden by a command line
option (like we do with out-dir)? You could specify another name for the
folder, or no folder at all.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#872 (comment)>,
or mute the thread
<https:/notifications/unsubscribe-auth/AABXvdVEUky97Y1Y7znelTRYYfN0fKx1ks5tXB7SgaJpZM4SM14H>
.
|
looks good! I think it is perfect for html. But is there something reason to collect all hashed file to I mean, how about I think, with special parcel ways, parcel needs more and more options to customize.. |
That's certainly an option. We could just put all of the hashed assets in the root. It was requested in #233 and elsewhere to put static files in a separate folder though, so I was trying to accommodate that. I guess maybe it makes it easier to separate things you might upload to a CDN and things you need to put on your webserver maybe? Why did you need that @npup? This option would look like:
Alternatively, we could make two roots: one for static assets, and one for HTML. So the output would be:
Then you could easily upload the html directory to your webserver, and static to your cdn. |
@devongovett parcel is useful when make static folder page like git page. However, two roots as default would not work with static folder page, and it looks little ugly with |
I like leaving them in the root as the simple default. Just provide a new option for the build directory for entry points (the non-asset files), defaulting to the same as @zeakd |
this feature is a must needed one.. +1 for this... i like the folder structure that @devongovett was mentioned here.
|
Please do not move url addressable and browser navigator files into a HTML folder. It is crucial that you retain the same folder structure from the web root as in your source directory for these files. If you fail to do this, it has implications on how a web server has to be set up, which dialers the ability to use standard static hosting and servers. It's important to put hashed assets into a specific folder with a predictable name so it gets easy to configure cache headers for these immutable files without having to configure regex matches in your server |
What I was after was a way to be able to be able to identify all generated
files _in the general case_.
This is useful for postprocessing as well as the SPA case. Being able to
put the generated assets in a sub directory with a name of choice solves
the general case bit (a bit better than just a nice default).
I don't have any special opinion on whether the HTML should go into a
directory of its own as well. I haven't had a need for that myself so far.
/p
2018-02-21 21:32 GMT+01:00 Devon Govett <[email protected]>:
… That's certainly an option. We could just put all of the hashed assets in
the root. It was requested in #233
<#233> and elsewhere to
put static files in a separate folder though, so I was trying to
accommodate that. I guess maybe it makes it easier to separate things you
might upload to a CDN and things you need to put on your webserver maybe?
Why did you need that @npup <https:/npup>?
Alternatively, we could make two roots: one for static assets, and one for
HTML. So the output would be:
dist/
├── html
│ ├── index.html
│ ├── about.html
└── static
└── index.a8b29e.js
Then you could easily upload the html directory to your webserver, and
static to your cdn.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#872 (comment)>,
or mute the thread
<https:/notifications/unsubscribe-auth/AABXvVHPJNTBeH_AkujDSmkRXWUmJVaHks5tXH1agaJpZM4SM14H>
.
|
I would suggest using base62 instead of hex as this leads to shorter hash IDs. This is especially powerful with a fast hash algorithm like xxhash. See also by little side-project: https:/sebastian-software/asset-hash |
I think this goes along with multiple entry points (#189).
|
In order for hashes of file contents to mean anything for cache busting and/or versioning, those files (and therefore hashes) need to be the same when you build with the same input code. This is not currently the case... I think something along the lines of #780 needs to be merged with or before this |
would it be sensible to make the naming configurable if needed (e.g. via a .rc file), and in that case just resort to old school get parameter cache busting? {
"html":"dist/[name].html",
"css":"dist/css/[name].css",
"js":"dist/js/[name].[package.version].js"
} |
Adding naming configuration should really not be needed. A good default is perfectly fine. Keep the name of the asset if there was one. If it's not a linkable entry point, inject a hash into the name to achieve content addressability. The only possible use for naming configuration would be if you have your static assets served through an external proxy CDN, so you need to update the urls from the parent asset from |
As @zeakd wrote: IMHO this rule is the best implicit "asset" folder configuration option (because it is somewhat explicit, but does not need any additional options). |
@ioss not gathering the content addressable files in a common directory makes it harder to configure a server to send out an immutable cache header for them |
@Munter I don't understand how the above "rule" from zeakd would prevent you from gathering files in a (or a handful of) common directory? Just have your assets in /src/assets/... and they would end up in /dist/assets/... and you would have the original proposal. Contrary: should you (for whatever reason?) do not want to send out immutable cache headers for some of the files, you'd have a hard time to exclude them, especially as they would change their name every time their content changes. |
Implemented this strategy in #1025. Please let me know what you think and help test it out! |
Closing since #1025 is merged. Please help test using the master branch - a release will hopefully come next week! |
I strongly support using an (optional) configuration file here. |
@yonimor scan your source folder, not your build artefacts |
This is a meta issue to discuss a number of things that have come up about file naming in Parcel.
build
command for revved filenames #753, Add --rev option to allow for bundle revisions #756, WIP: Content-hash bundle names #829I think we can come up with a cohesive file naming strategy that meets all of these needs.
index.a8b29e.js
, except in the following cases (taken from the rules outlined by @Munter here). In those cases, we use the original filenames.<a href>
<meta http-equiv="refresh">
humans.txt
,robots.txt
,.htaccess
,favicon.ico
dist/assets
e.g.dist/assets/index.a8b29e.js
. This would be flattened as it is currently, sosrc/some/path/something.js
would be placed in e.g.dist/assets/something.fd5se2.js
.<a href="/some/path/something.html">
the output file would bedist/some/path/something.html
.-o
or--out-file
CLI option, which would override the default name for the entry file. If not provided, and the entry file matchesmain
in package.json, use the package name.The only case where this breaks down is if the input path started with
/assets
- which is the folder we're already using for static things. Not sure what to do about that: I guess we could try to generate a unique name for the assets folder or something. Open to suggestions here!Otherwise, I think this strategy solves most of the issues listed above. Please let me know your feedback and make any suggestions you think would improve this strategy!
cc. @zeakd @songlipeng2003 @ssuman @Munter @benhutton @shanebo @leeching @gamebox @npup
The text was updated successfully, but these errors were encountered: