Question

App platform looks like it's caching package-lock.json

Posted on March 28, 2024
DigitalOcean App Platform Node.js
Asked by Steven

We are encountering an issue where it seems like the DigitalOcean App Platform app is caching the package-lock.json. We had a working deployment, but after a modification, it broke. Even after reverting the modification, the deployments continued to fail. A forced rebuild and deployment did not help either.

The error:

[2024-03-28 21:23:13] │ > Portaal@1.0.1 copyfiles
[2024-03-28 21:23:13] │ > copyfiles -u 1 "src/**/*.{html,css,scss,ttf,woff,woff2,eot,svg,jpg,png}" dist/
[2024-03-28 21:23:13] │ 
[2024-03-28 21:23:13] │ sh: 1: copyfiles: not found
[2024-03-28 21:23:13] │ building: exit status 127
[2024-03-28 21:23:13] │ ERROR: failed to build: exit status 1

Copyfiles is part of package.json and works locally.

We then created a second app and linked it to the same repository with the same settings, and this one works flawlessly! What stands out is that the broken app downloads fewer packages than the new one. It seems like a file is persistently cached.

Logfile broken app:

[2024-03-28 21:22:51] │ added 1023 packages, and audited 1024 packages in 1m

Logfile working app:

[2024-03-28 21:19:05] │ added 1076 packages, and audited 1077 packages in 25s

What we’ve tried:

Forced rebuild
Used a different Node and NPM version
Deleted node modules in a local environment and regenerated package-lock.json. All without result.
npm cache clear --force && npm install --only=dev && npm run build && npm prune --production command added to broken app

Edit: Looks like a found a fix. The solution can be foundhere:

Added environment variable:

NPM_CONFIG_PRODUCTION=false

But the question remains: why does one app work while the other app requires this variable, even though they both use the same codebase and settings?

Submit an answer

This textbox defaults to using Markdown to format your answer.

You can type !ref in this text area to quickly search our full set of tutorials, documentation & marketplace offerings and insert the link!

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.

Bobby Iliev

Site Moderator

• July 5, 2024

Hey!

Just coming across this question here and am happy to see that you’ve got this working! Thank you for sharing your solution here!

To add some extra details here, the issue you’re experiencing aligns with what DigitalOcean describes in their documentation about missing module errors in Node.js apps on App Platform.

Basically, the core issue is likely that the ‘copyfiles’ module is listed in the devDependencies section of your package.json file instead of the dependencies section.

The App Platform, by default, prunes the devDependencies during the build process to optimize the production deployment. This is why you’re seeing the “copyfiles: not found” error.

The discrepancy in package counts between the broken app (1024 packages) and the working app (1077 packages) is likely due to the inclusion of devDependencies in the working app.

By setting NPM_CONFIG_PRODUCTION=false as an environment variable instructs npm not to prune the devDependencies, which is why it resolved the issue.

The reason one app works while the other doesn’t, despite using the same codebase, is likely due to different environment configurations. The working app might have had NPM_CONFIG_PRODUCTION=false set automatically or manually.

Recommended Solutions (in order of preference):

Move ‘copyfiles’ to the dependencies section in your package.json. This is the most appropriate solution for production deployments.
If ‘copyfiles’ is truly only needed for development, adjust your build process so that it doesn’t rely on devDependencies for the production build.
Set NPM_CONFIG_PRODUCTION=false as an environment variable in your App Platform configuration. While this works, it’s less ideal as it includes all devDependencies in your production deployment.

This situation isn’t related to caching of package-lock.json as initially suspected, but rather to how App Platform handles dependencies during the build process. For anyone interested, the documentation clarifies this here