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

[surma]

🙋 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’d 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]

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):

parcel/packages/namers/default/src/DefaultNamer.js

Lines 93 to 95 in 619cbaf

	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]

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]

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]

(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]

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]

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]

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

[mischnic]

@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]

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]

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...