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鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

Opt-out of the hash-in-filename pattern for individual files #4553

Closed
surma opened this issue Apr 30, 2020 · 10 comments
Closed

Opt-out of the hash-in-filename pattern for individual files #4553

surma opened this issue Apr 30, 2020 · 10 comments

Comments

@surma
Copy link

surma commented Apr 30, 2020

馃檵 feature request

Sometimes it might be desirable to not put a hash into the filename of a resource. Parcel already does this automatically for ServiceWorker, for example. I鈥檇 be great if, as a developer, I could also opt out of this behavior for other files.

馃拋 Possible Solution

Is this something that could be deferred to the plugin interface?

@mischnic
Copy link
Member

mischnic commented Apr 30, 2020

I really need to finish up the docs....

Is this something that could be deferred to the plugin interface?

The namer plugin is responsible for that (you just have to make sure that your bundle filenames/paths are still unique):

if (!bundle.isEntry) {
name += '.' + bundle.hashReference;
}

(For some context, the HTML dependency visitor sets isEntry for the serviceworker url, which propagates to the resulting bundle. But in the namer you can also say bundle.getMainEntry().filePath to differentiate bundles based on their main entry.)

Does that answer your question? In that case I would close this as a duplicate of #4320

@jakearchibald
Copy link

jakearchibald commented Jul 10, 2020

I think, to close this, the developer would need to be able to opt out of hashing for a specific file. This could be via a plugin though, so if that's possible with plugins, but not documented, then this can be closed in favour of #4320.

@jakearchibald
Copy link

jakearchibald commented Jul 10, 2020

The use-case here is "I like my files to be hashed, except this one particular file". It's great that Parcel does this by default with SW and HTML, but I think this should be generally configurable, otherwise developers will need to wait for Parcel to add in exceptions for their particular case (if that even makes sense).

The naming plugin looks like a good bet, but having to publish a project-specific plugin to NPM seems like an unacceptable barrier. Writing a general plugin would be ok if it could be configured project by project, but I can't see a way to provide plugins with configuration.

@mischnic
Copy link
Member

mischnic commented Jul 10, 2020

(The namer is a very simple plugin type, so it's page is rather complete already: https://v2.parceljs.org/plugin-system/namer/ , though a more real-world example is planned))

project-specific plugin to NPM

-> #4321

We'll probably allow that because the current workaround of setting up a monorepo to have a plugin "package" doesn't provide any technical benefits compared to a local plugin (regarding caching).

I can't see a way to provide plugins with configuration.

The config-loading logic that powers babelrc/postcss/... in Transformers will be ported to all other plugin types as well, so caching would work correctly as well.

(And generally, trying to prevent a parcel.config.js from emerging is somewhat of a dilemma)

@jakearchibald
Copy link

jakearchibald commented Jul 10, 2020

The config-loading logic that powers babelrc/postcss/... in Transformers will be ported to all other plugin types as well, so caching would work correctly as well.

Sounds good!

(And generally, trying to prevent a parcel.config.js from emerging is somewhat of a dilemma)

Fwiw, "zero config" was never a selling point to me. I read it as "Parcel will do what it wants, and if you want something different, good luck!"

Parcel's selling point for me is that it's "web aware" throughout. It's understanding of HTML, CSS etc is first-class.

@mischnic
Copy link
Member

mischnic commented Jul 10, 2020

Yeah, I listed to your recent HTTP203 episode.
The (new) idea for Parcel 2 is rather "zero-config = no config is required" while making everything overrideable (e.g. a babelrc is used as is without merging with preset-env, have full control over code splitting/shared bundles with a bundler plugin, ...)

@mischnic
Copy link
Member

mischnic commented Jul 10, 2020

Closing this in favour of the issues for missing docs/local plugins...

@mischnic
Copy link
Member

mischnic commented Jul 10, 2020

@jakearchibald So would a custom plugin that can override a specific bundlename and leave all other bundles to the default namer (https://v2.parceljs.org/plugin-system/namer/#overriding-names-for-specific-bundles) pass your test?

For Rollup, you wrote that writing a plugin to do this is a "non-trivial effort". Is this because the problem is having to write a plugin itself or because Rollup's plugin architecture makes this hard to do?

@jakearchibald
Copy link

jakearchibald commented Jul 10, 2020

Rollup lets you control the naming of a file when you emit a chunk or asset, but if you aren't doing that (eg, the chunk is created by import() in code, or code splitting, or by an unrelated plugin), then you're left with doing a string find/replace in the bundle at the end, which is risky and will break source maps.

Rollup solved this by providing a callback for entryFileNames https://rollupjs.org/guide/en/#outputentryfilenames, although a plugin which had a similar callback would be fine.

If I'm reading the docs correctly, it looks like https://v2.parceljs.org/plugin-system/namer/#overriding-names-for-specific-bundles would pass, as long as it can be used without publishing the plugin separately to npm.

@freehuntx
Copy link

freehuntx commented Sep 3, 2020

I really dont understand why parcel makes such simple things so complicated.
Getting another dependency in your project just to stop parcel from putting undesired hashes in file names.
Or take a workaround and listen EVERY js file in your entries so parcel thinks its an entry and stops this behaviour.
I dont like this at all...

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