feat:added no content hashing option to build cli

[egfanboy]

Based on request from #1885

• Added --no-content-hash CLI option to parcel build
• Changed the exiting of the process to occur if options.watch is false instead of looking at NODE_ENV

CLOSES #1885

[devongovett]

I'm curious why you would want to disable content hashing?

[egfanboy]

I am working on a project where we are required to commit the bundle. Therefore, in PR we would get huge changes since sometimes the bundle was sometimes hashed and sometimes not.

We had to move to the API way of doing things to avoid this but since we would like to stick to the CLI bundling approach we decided to open a PR to add that functionality.

[raphaklaus]

As far as I'm concerned, version 1.9.7 has the following behaviors:

On parcel, the content hash is disabled (probably to prevent tons of files in dist folder).
On parcel build, the content hash is set to enable by default (for differentiation porpuses, cache busting, etc...).

I think the current Parcel behavior is contradictory. The option should be consistent in both cases. Taking into account the bug I found in #1886

I can foresee one outcome if the team decide to go on with the content hash as default for both commands:

On parcel, dist will grow bigger in file quantity due to the different content hashes, so a new option could bear: --clean-up which will clean the dist folder and bundle again with the new content hash. The option could be the default, however.

Summarizing (supposing content hash is the default for all), my proposal:

parcel - It generates bundles with different content hashes (need to work on this although #1886)
parcel --clean-up - Same as above, but keep your dist lightweight
parcel build - It generates as it does currently
parcel build --no-content-hash - What the PR opener is trying to achieve. Hashes by filename identity

Best

[devongovett]

I don't think we should change the behavior here.

[numical]

+1 for this.
We are using parcel to generate React code that creates content in existing pages generated server-side by a Java .jsp container.
Hence we need the .js files to have a consistent name across releases.
Currently have to use explicit Bundler code to achieve this as per the docs.
A CLI option would be much cleaner.

[kleinfreund]

What exactly does this do right now? As far as I can tell, specifying --no-content-hash for parcel build doesn’t change anything. The content hashes are still included in the file names.

[numical]

The filename hashes are then based on the filename, not the file contents; aka static filenames

…

---- On Sun, 30 Sep 2018 07:47:12 +0000 notifications@github.com wrote ---- What exactly does this do right now? As far as I can tell, specifying --no-content-hash for parcel build doesn’t change anything. The content hashes are still included in the file names. — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

[Andrew-Dyachenko]

What exactly does this do right now? As far as I can tell, specifying --no-content-hash for parcel build doesn’t change anything. The content hashes are still included in the file names.

+1 the --no-content-hash flag using has no effect. The names of the building files still contain a hash in the file names. We're currently need static file names in the project

How to solve this?

[mischnic]

doesn’t change anything

It does: by default, file hashes are calculated based on the file contents. With that flag, they are based only on the file path.

[Andrew-Dyachenko]

Ohhhh!

I checked the launch of the assembly with flag --no-content-hash and without.
If you change something in the files and run files with the --no-content-hash flag, then the hash will not change. Since the path to the file remains the same. If run without a flag, the hash will change based on the changed content.

Looks like you're right! A little unseemly flag. It is necessary to supplement the official documentation with an extended explanation!

@mischnic Thank you!

[Andrew-Dyachenko]

Nevertheless, in my opinion, we still need a flag that would permanently disable the hash in the file names. I believe that such a flag will be called: --no-hash