We Keep Coding

Javascript: What is eslintcache file and why is always generated in create react app

What is eslintcache
Why it is always auto generating on the react app.
eslintcache

eslint goes over your code and reports stylistic errors. Usually going over the whole code is unneccessary, because you only changed a few files since the last run. To be able to track which files changed, and which errors occured in the files which were not changed, eslint is writing a cache (into the file you found).
Usually that file is supposed to be in /node_modules/.cache/, so you usually won't notice it. That it resides in your working directory is a bug.

Webpack generate different chunks with the same contenthash

I've a Webpack 4.1 configuration that use code splitting and output chunks names using a pattern like myproj-[name]-[contenthash].chunk.js.
I'm copying all of the production bundle files, for every version, in the same directory on the server, being sure (until now) that chunks are unique and I have no clashing.
Today I found an issue releasing a new version of the application: I've a file named myproj-modulex-0bb2f31cc0ca424a07d8.chunk.js that was also generated with the old version (that's the scope of contenthash, isn't it?). I'm expecting that the content of the file is identical but it isn't.
There's only one character changed (the array index). The chunk start with...
(window.webpackJsonp_XXXX=window.webpackJsonp_XXXX||[]).push([[7],{"2d0274e27fde9220edd9"...
...while the old version was using ...push([[6],....
One of the difference of the new version from the old ones is that I added new code splitting points.
So: it seems that new split points changed chunks order, but webpack still use the same generated filename (probably because contenthash is referred to the real module content?).
The issue is critical: when the new file is copied on the server it overwrite the old file and so client using old version are not working anymore because chunk is loaded in a wrong position on the push array (I guess).
Error is:
"Error: Loading chunk 6 failed.
(missing: https://.../myproj-xxx-0bb2f31cc0ca424a07d8.chunk.js)"
There's a way to fix this issue, maybe naming pushed chunks, or specifying the order, or generated different hashes? chunkhash ?

Webpack uses ids as a chunk references and those ids are not guaranteed to remain the same for the same chunks among different builds. contenthash is used for files extracted by ExtractTextWebpackPlugin. The same source content will get the same contenthash but the generated file may differ due to id changes.
Try using myproj-[name]-[chunkhash].chunk.js instead.
Also take a look at optimization.moduleIds and optimization.chunkIds settings.

Add md5 hash to file URL for optimal caching in Node.js

Appending a file's hash to its url seems like a common thing to do to ensure files can have infinitely far cache expiration dates without causing problems when a new version of the file is available.
How is this task usually accomplished in Node.js?
Being clearer
Instead of asking the browser to load main.js, I would ask for main.085cc38ce00780e9365ee07275bfb8d8.js, where 085cc38ce00780e9365ee07275bfb8d8 is the file hash. So that when I change the content of my main file, the hash will also change and it will be as if the HTML were requesting a completely different file.
The solution I'm looking for must tackle:
Renaming the file or mapping the name-with-hash to name-without-hash
If files are renamed, getting my HTML markup to reference the correct file name with hash.
For context: My current build pipeline uses Gulp and docker, so I rebuild everything on every change, but I am open for any solution.

Watchify not looking at changes in parent folders

I have a bunch of apps under a single folder with a common dependency.
/app/app1/src/main.js
/app/app2/src/main.js
/app/app3/src/main.js
/common/tools.js
Now several instances of Watchify is running for all of these and if I change anything in any of them, that app will be rebuilt with browserify and reactify. The idea here is to have all the apps only get their own compiled file and not one single huge javascript file containing all the apps. Good so far!
Now the entry point, main.js, of each app starts out something like this
var tools = require('../../../common/tools');
var something = require('./something');
If I make a change in the app specific something.js, that app will be rebuilt and everything works as expected. However, if I update something in tools.js, which have several apps depending on it, that doesn’t happen. In theory, that should trigger a rebuild of all the apps since they all require it, but that doesn’t seem to be the case.
If I change something in tools.js, I have to go to each app and re-save some file in it for it to be rebuilt and get the changes I made.
Is Watchify only looking at subfolders and not parent folders or could there be something else going on here?

I don't think that is how it works.
Watchify will watch the specified folder(s) and trigger a callback when there are some changes.
Changes on other files outside of the watched ones (even when this are required on your app files) will NOT trigger a change, thus wont be detected.
Solution ? Probably redefine what needs to be watched.

Forcing the browser to reload css/js only if they have changed

There are a lot of questions and answers on SO related to my problem [I want the browser to cache js/css forever. During a new release if some of the js/css files have been updated, the browser should reload and cache them.]
This solution seemed most appropriate to me :
What is an elegant way to force browsers to reload cached CSS/JS files?
However, there is just one thing that I am unable to figure out.
The solution makes use of last_modified_time. However, I am not allowed to use it. I need to use some other mechanism.
What are the options? Is there a possibility of pre-calculating the versions during build and updating(replacing) them in jsps via build script (before deployment, so that the version numbers are not calculated on run time)? Any existing tool for this purpose? I use Java/Jsp.

We always use
file.css?[deploytimestamp]
This way the CSS file is cached for each deployment at the client. The same goes for our minified javascript. Is this an option for you?

It may not be the best way, but this is what I am doing now:
All of my js/css have a [source control = svn] revision number
References in my jsp are like /foo/path1/path2/xyz000000/foo.
Build Step 1 - Generate a map of css|js files and their revision numbers
Build Step 2 - Replace xyz000000 references in jsps with a hash of svn revisions
A rule in url rewriter to direct all /foo/path1/path2/xyz<767678>/foo. to /foo/path1/path2/foo.[js|css]
Infinitely cache the css|js files
Whenever there is a commit, the revision number changes and so do the references in .jsp

Generate an md5-hash of each css file after deployment. Use this hash instead of the timestamp in the url of the css.
file.css?[hash of file.css contents]
It may be wise to calculate the hashes once after deployment and store them to gain some performance. You could store them in a database, or even in a PHP array in a separate file that is included in your website code.