react scripts build generate new hash even if the code not changes-CodePudding

The

I want every build to generate new unique name to js, css and html files.

CodePudding user response：

If the input is the same, if you did not change anything in the codebase, webpack will ALWAYS produce the same hash. This is the main property of a hash function. So you have to somehow always change the codebase. To achieve this you can write to a js file and import it in app.js so webpack will see that file's input has changed. In your webpack.config.js

const crypto = require("crypto"); const fs = require("fs"); const content = crypto.randomBytes(8).toString("hex"); const value = JSON.stringify(content); // we have to write a valid javascript fs.writeFile("src/test.js", `export const a=${value}`, (err) => { if (err) { console.error(err); } });

this test.js has no effect on your code. So you could safely import in app.js

import "./test.js";

If you dont import it will not work. Because webpack will read only imported code.

in webpack.config.js i defined the filename like this

output: { filename: "[name].[hash].js", path: path.join(__dirname, "dist"), publicPath: "/", },

every time I run npm run build it creates a different hash. Proof of work:

CodePudding user response：

UPDATE

https://github.com/timarney/react-app-rewired states:

As of Create React App 2.0 this repo is "lightly" maintained mostly by the community at this point. ⚠️ Please Note: By doing this you're breaking the "guarantees" that CRA provides. That is to say you now "own" the configs. No support will be provided. Proceed with caution. "Stuff can break" — Dan Abramov https://twitter.com/dan_abramov/status/1045809734069170176

And specifically it refers this - 6 years old - comment:

We don't intend to provide Webpack specific overrides because it will be very fragile. People will start depending on specific loaders and plugins and we won't be able to improve the overall experience. We would like to encourage you to file issues about specific pain points you encountered. We understand you want to configure some things. Please help us understand what these things are, and why you want to configure them. We will look at those requests holistically and perhaps find another solutions, or maybe introduce some minimal configuration.

I would say this is the most probably explanation why your setup does not behave as intended.

If I understood you correctly -- you want to have all output of particular build be tagged with the same unique version and it seems the issue you are experiencing is present when deploying / building in production mode.

If that is the case your setup:

const buildHash = uniqid(); config.output.filename = `static/js/[name].${buildHash}.js`; config.output.chunkFilename = `static/js/[name].${buildHash}.chunk.js`;

seems legit (calling it buildHash is probably a misnomer though; it is more like buildVersion).

I am not sure how config-overrides.js exactly works and how it relates to webpack, but if it works correctly on your local machine you should see the output from your console.log in the terminal and output files should be properly tagged with uniqid. Is that a case?

Assuming a positive answer to the above question: you should investigate why deployment does not pick it up. In such a case webpack uses default setup.

Assuming a negative answer: anyway weback uses its default setup and config-overrides.js is ignored completely.

To help you further please provide more context of how exactly your build / deployment is setup.

In another comment you wrote: ok, I don't have webpack.config.js, I have config-overrides.js, can I write it there? - It sounds to me that config-overrides might be not picked up at all.

As an ugly hack and if you do not need hash in the output name you could override output.hashFunction to return the build version:

const buildVersion = uniqid config.output.hashFunction = () => buildVersion; config.output.filename = `static/js/[name].[hash].js`; config.output.chunkFilename = `static/js/[name].[hash].chunk.js`;

This could marginally speed up the build, but is very unintuitive and anyway your original setup should work fine without any hacks.

As a side note both output.filename and output.chunkFilename accepts a function, which allows to set arbitrary name.