I have a static site deployment that is built from a TypeScript+React app. Any time a deployment builds with a cached node_modules directory, I get a build error. Any time I change yarn.lock and force the app to be built, it succeeds.

My current theory is that I had a TypeScript build error present ~10 deployments ago ago due to an outdated @types/ package in devDependencies. I removed the package from package.json and yarn.lock which led to a successful build. The next build, containing only completely unrelated changes, failed with the error I had seen previously. Since then I have upgraded random packages to force yarn.lock to change and each time the build is successful. But each time a cached node_modules is used the build fails.

I’ve confirmed that this problem package, @types/history, is still in node_modules/@types/ in the cache (by adding ls node_modules/@types/ to my yarn build command). I’ve confirmed it is not in yarn.lock and if I nuke node_modules locally and yarn install locally it is not present.

How is node_modules caching done? If old caches are merged forward, then perhaps the outdated @types/ package is still present and thus breaking my TypeScript build.

Is there a way to delete the node_modules cache and start it over? Or to disable the use of the cache? Or, do you have advice for reproducing this issue locally? Thanks.

These answers are provided by our Community. If you find them useful, show some love by clicking the heart. If you run into issues leave a comment, or add your own answer to help others.

×
Submit an Answer
1 answer

Here’s something that worked but it’s annoying:

"build": "rm -rf node_modules/@types/ && yarn install --check-files && GENERATE_SOURCEMAP=false react-scripts build",
  • Hi @jasonprado 👋🏼

    How is node_modules caching done? If old caches are merged forward, then perhaps the outdated @types/ package is still present and thus breaking my TypeScript build.

    The node_modules cache is directly tied to the contents of yarn.lock (or package-lock.json) after yarn install (or npm install) is run. The modules are cached before the app’s custom build command is run, so if the build command makes changes to the node_modules directory, those changes will not be included in the cache and ultimately in the following build.

    Although I don’t think that caveat is related to what you’re seeing. I will look into this further, but I suspect that this is actually a bug like you said where the cached node_modules directory is merged with the new one rather than replaced.

    In the mean time, I would recommend clearing the build cache and seeing if this problem persists. In the control panel, navigate to your app, click on the Actions dropdown in the top-right corner of the page and then on “Force Build and Deploy”. Select “Clear Build Cache” and hit Deploy.