11902 2017-08-06 23:37:27 +0000 updating npm4 to npm5 2020-05-17 02:40:27 +0000 1 1 7 Build System, Metadata & Runtime OE-Core core unspecified x86 Multiple RESOLVED FIXED Medium normal Future 10653 1 stanley.cheong.kwan.phoong unassigned bluelightning henry.bruce jeanmarie.lemetayer meta.mr.watcher meta.watcher randy.macleod richard.purdie --- --- No (bug/feature does not impact docs) oldest_to_newest 75676 0 stanley.cheong.kwan.phoong 2017-08-06 23:37:27 +0000 75931 1 bluelightning 2017-08-17 00:27:19 +0000 Stanley - can you please include some brief details based on our earlier discussion about the motivations for this upgrade and then reassign it back to me? Thanks. 76012 2 stanley.cheong.kwan.phoong 2017-08-20 23:53:58 +0000 sorry about that Paul, sure thing. npm@4 lacking a few feature that would ease up the bitbake fetcher process: - Has faster installs - Offline support (if you already installed the modules) - Lock file for deterministic installs Hence, using Yarn and npm@5 as a possible alternative is considered to tackle these issues. After some discussions with Paul here's some summary: Yarn would require too much change internally in order to adopt Yarn and Yarn would also require a different workflow. npm@5 requires lesser changes but doesn't mean that there's no change required. npm@5 has all three features that Yarn also provides including lock file to lock the versions of the dependencies. Simply running a simple "npm install" would automatically trigger the package-lock.json file to be write the version into. No longer a need to explicitly call npm strinkwrap and etc... The introduction of "package-lock.json, is a new, standardised lockfile feature meant for cross-package-manager compatibility (package-lock.json), and a new format and semantics for shrinkwrap. The other good news is the installation now take approximately half the original time taken by npm@4. Additionally, package-lock.json will be automatically created unless an npm-shrinkwrap.json exists. Other new feature is "--prefer-offline" and "--prefer-online", the first option will make npm skip any conditional requests (304 checks) for stale cache data, and only hit the network if something is missing from the cache. While the "prefer-online", option will force npm to revalidate cached data (with 304 checks), ignoring any staleness checks, and refreshing the cache with revalidated, fresh data. Also, another thing "--save" is no longer necessary, to force an npm install to write into the package.json. This should ease out a few issues faced with npm@4 especially regarding the lock file and versions. 78987 3 henry.bruce 2018-01-10 06:44:59 +0000 Note that only even versions receive LTS (see https://github.com/nodejs/Release#release-schedule), so if investing more effort here, go for v6 or v8. 87219 4 jeanmarie.lemetayer 2020-05-17 02:40:27 +0000 Current version: - node: 12.14.1 - npm: 6.13.4