I wish it was as easy as adding a flag! But it actually is that big of a breaking change.
npm ci relies on ~/.npm, not a node_modules directory. In fact, if node_modules is present when npm ci runs, the directory will be removed. So we would have to switch to caching ~/.npm, and we would need to evaluate the impact on the time it takes to download/upload cached files that way instead.
There’s also the fact that if there are any discrepancies between package.json and package-lock.json (i.e. missing dependencies), the build will exit with an error. What if a build takes minutes to detect this discrepancy before failing? Our customers pay for build minutes, even for failed builds, so we need to make sure we do our due diligence here and minimize the amount of time before failure as much as possible.
Plus npm ci requires a package-lock.json, which not everyone knows how to generate or include. And even if we design our npm ci implementation to fall back to npm install when npm ci breaks, which is something being discussed, each execution path has to be written, tested, and incrementally rolled out behind feature flags to make sure we don’t break previous functionality that customer’s are relying on.
Within that, this discussion is just one of many discussions about our build system that is happening between our product and build engineering teams. As I mentioned earlier, I’ve linked this thread to voice support for npm ci and we will be sure to follow up here with any updates. In the meantime yarn install --frozen-lockfile will be the best alternative.