heroku / heroku/buildpacks-nodejs
State where there is package.json but not package-lock.json
- Dominant language
- Rust
- Stars
- 28
- Forks
- 17
- Avg merge
- 1d 16h
- Merged PRs (30d)
- 14
Description
When there is a package-lock, the process installs the dependencies using npm ci. But if there is no package-lock and yet there is a package file, the process still installs Node and npm… and just does nothing with them, as the prebuild/build/postbuild scripts are not even attempted even if present in the package file.
I don't understand how that makes sense.
I have the practice of not checking out my package-lock, I know it's not a majority shared view but it's not really the point.
If you decide that the boundary between Node and non-Node is package-lock, then let it be package-lock, and not install Node at all. I wouldn't be happy about that choice, but not less than the current way it functions which doesn't support my workflow either.
Now you could say "package-lock is for dependencies, a package without a package-lock is a Node package without dependencies, so we will be in Node mode without installing dependencies". I don't agree with that statement, but it's coherent.
But then why does it not run the build scripts ? That doesn't make sense.
I think the current state of inconsistent limbo for those projects falling in between is counter-intuitive, and if I didn't have someone "in the know" telling me very fast that package-lock was mandatory with this, then I would have probably spent days trying to figure out why the install and build steps didn't trigger.
My proposes solutions would be :
- automatically run `npm install --package-lock-only` before `npm ci` in the case there is no package-lock,
- or trigger `npm ci` regardless of the presence of package-lock, allowing the entire process to fail if a "preinstall" step wasn't defined to create a package-lock file. At least there would be a tangible error to look at, rather than a bunch of steps missing for no apparent reason.
- Or as proposed below, just make it an unavoidable error. That also would make it a tangibld error to see rather than some steps missing.
Contributor guide
Research direction
Start by tracing how package.json and package-lock.json presence selects the npm ci, Node installation, and prebuild/build/postbuild steps. Compare the no-lock path with the package-lock path and inspect the existing tests around those decisions, if available. Done means the behavior for a package.json without a lockfile is explicit, consistent, and covered by tests.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- javascript, nodejs
- Domain
- build-system, devops
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 45/100