+1 from me
I think this goes hand-in-hand with
https://github.com/apache/cordova-plugin-file/pull/473
On 2021-09-12 7:34 a.m., Bryan Ellis wrote:
+1, start pushing it
It is said to be backward compatible for npm v5 and v6 but will see warnings.
npm WARN read-shrinkwrap This version of npm is compatible with
lockfileVersion@1, but package-lock.json was generated for lockfileVersion@2.
I'll try to do my best with it!
As it says, "I'll try to do my best with it!"
It implies possibilities of failure, but if it happens, people should upgrade
to npm v7. The package-lock.json is only a part of the development and testing
workflow. It does not affect production.
As for our CI, if it happens to become an issue, we can:
* remove node 12 & 14 from the testing workflow
* force upgrade npm to v7 and tell people that we do not support older npm.
Anyone who uses the standard node's package npm must upgrade.
* update the CI workflow to delete package-lock.json on each run to remove the
issue with only an increased run time.
On Sep 12, 2021, at 6:51 PM, Niklas Merz <niklasm...@apache.org> wrote:
Hi all,
I have another proposal regarding NPM. Do we want to upgrade our
lockfile versions? This came up during a PR for package-lock.json
updates: https://github.com/apache/cordova-lib/pull/879#issuecomment-
917483860
From my understanding the new version "2" is backwards compatible and
default in npm v7. If you can `npm install` with npm@7 it automatically
updates the lockfile by default. Which means we could accidentally
commit it. Details from the docs:
https://docs.npmjs.com/cli/v7/configuring-npm/package-lock-
json#lockfileversion
As it is backwards compatible I think an upgrade would be fine. What do
you think?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org
