In the given scenario, new Dev A has a new version of npm (8.3). He does a clone of the repo and npm says the package.lock file needs to be upgraded from lockFile version format 1 to version 2. Then he checks that in. So now the repo has a lock file with format version 2 and other devs pull that down.
Time goes by with no problems. Then Dev B, who's on version 6.13, installs a package. Is it normal that the lock file will change back to version one FROM version 2? In other words, each time a dev with a different version of npm that employs a different format, upgrades or installs a package, is it normal that it changes the lockfileVersion format over and over depending on their npm version and its format? Or should it stay with lockFileVersion 2?
Trying to identify what happened recently with our packages, and I'm looking to exclude this as a possible issue.
From what I read fileLockVersion 2 is supposed to be backwards compatible. But is it supposed to change back and forth like that? I wouldn't think so because how can someone with version 2 (Dev A) use version 1 if it was required to upgrade to version 2 in the first place?
So am I correct that once it's on version 2 it should stay that way? And if so, what would cause it to go back to version 1.
Thanks
No, it's not normal for developers to keep flipping versions like that, but it's fairly common for it to occur. We also had this happen specifically with package-lock.json so we told everyone to upgrade, and we made sure to upgrade all of our build agents. Similarly, in Visual Studio solutions some developers occasionally changed the version of VS back and forth from 2017 to 2019 a few times before we told everyone to just upgrade to 2019.
Generally it's best to avoid it if possible.
Related
what is the best practice to upgrade the dependency v-calendar from beta to the latest version v2.3.0?
I know the question is opinion based, but I am new to the field, what are the pros and cons of the way to do the upgrade.
We use "v-calendar": "~1.0.0-beta.14" in production. The latest version is currently v.2.3.0
I can think of two ways:
update to the latest version with yarn add v-calendar#latest?
upgrade incrementally until the latest version is reached with yarn upgrade "v-calendar"?
What should I do to reach the latest version? thank you
ps. we are using vue: ~2.6.10
Unless the package you are using has an upgrade guide (99.99% of them don't), there is absolutely no point in doing an incremental upgrade. If it has an upgrade guide, read and follow its instructions.
The easiest way to upgrade is to change the package version to latest (in most IDE's if you press Ctrl/Cmd and hover the package number shown in package.json a tooltip will show you currently installed version, latest wanted version and latest available version). After you changed it (by typing the latest version in), run yarn install.
In the vast majority of cases, that's all you need to do, because most packages are built with backwards compatibility (existing features remain and new features are being added). If that's not true in your case, you'll have to reimplement it following their documentation. Typically it's no big deal.
Also, note there is no risk in attempting to change to a newer version. If things break, you just go back to package.json, change version back to lower, run yarn install again and everything is back to square one.
I'm trying to upgrade a very old version of Aurelia CLI project v0.24.0 to the current version v1.2.3. I've tried to follow the steps from this link from the docs but when I try to run it I receive this error:
So my question is what is the best approach to upgrade it from such an old version to the newest one?
Just a screenshot of error is too little info to give proper advice on. And between the currently latest version of v1.2.3 and v0.24.0 (Jan, 2017) there's roughly 3 years. Fun part is, you'd be amazed at relatively how little Aurelia core itself has changed. Simply because a lot remained stable.
Most impactful changes will be in either:
aurelia_project folder, with the build and config routines
bundler config (system.js, webpack, requirejs - whichever you've used)
That being said, this does not necessarily mean that your dependencies have also remained stable in those past three years. Especially in Javascript world. To accommodate for this, I would suggest:
Create a blank, new project with the latest Aurelia CLI
Copy/paste over the /src folder from your old project to your new one
Take in consideration specifics, like package.json from your old project and migrate them by hand (reinstalling) in your new project
Again, try to keep your bundler similar and you will have relatively little changes. But if you choose you want to migrate from System.Js to Webpack, it'll be a bit more hassle. But arguably, rewarding in the end if your project needs to be kept alive for a longer while.
Considering the age of your old project, restarting with a clean setup and config is what I would consider to be "the best way" to retouch only the necessities.
Some time after the release of Elm19 I published a library, which I needed for an Elm18 code base: thought2/elm-wikimedia-commons.
This worked well, it's listed in the community driven Elm18 package database: https://dmy.github.io/elm-0.18-packages/, can be installed and all good. Except the fact that the documentation is not shown in the package details, but that I heard is a known bug there. (But still I think this is very bad)
But the main problem is now, how to migrate the library to Elm 19: The actual migration steps are done and live in the master branch of the repo: http://github.com/thought2/elm-wikimedia-commons
The Elm18 versions proceeded to 1.1.0 in the meanwhile and after the migration there had to be done an API change, so I'd assume the latest version to become 2.0.0. If I add this to elm.json, the command elm publish tells me that this would be the first version and I should change this. Which is not right.
After a bit of research, I found out that the package (among other 18 ones that have been published in the same time period) is not listed in this json: https://package.elm-lang.org/all-packages This should contain all packages regardless of versions.
Any ideas what to do? This is really blocking my development, as I'm stuck in both lands now: 18 and 19. Would appreciate a lot if someone has some hints or solutions for me!
You shouldn't need to mess with the version number specified in elm.json.
If you set it back to the version of the package that is already published and run elm bump the elm program will look at the changes you've made to the package's API and set the new version accordingly.
Looking at https://github.com/thought2/elm-wikimedia-commons it doesn't look like any of your upgrade changes were breaking changes to your package API so the version won't be a 2.x.x, it will be a 1.x.x.
You'll need to remove the 2.0.0 git tag as well and instead add a tag for the version that elm bump tells you that your package is.
We're using NodeJS for some projects and are faced with an issue that must have a simple solution (seeing as nobody else seems to have the problem).
In the packages.json there are a bunch of dependencies mentioned with a minimum version, each of which may have overlapping dependencies of their own. The default way a dependency is added is using the ^ operator which seems to mean 'compatible with' or 'same major version, but minor versions may differ'.
The way I understand npm to work is on npm install to take the highest minor version available that matches. Unfortunately 'compatible with' is not quite as enforced as you'd hope.
The situation this puts us in is that for instance on a developer machine version 1.1.0 is installed, but between development and publishing a new version 1.2.0, that has a bug, is introduced. On our build machine a fresh build is made which ends up using 1.2.0 and we've introduced a bug that wasn't there in development.
We tried changing the ^ operator to = for instance, but this gives us trouble when dependencies have subdependencies that aren't compatible with the requested version.
All in all I'm a bit confused, but this thing keeps biting us anytime something changes since the development machines don't do anything on npm install if the package is already there, but the build machine always gets fresh copies.
I know from NuGet that it always takes the lowest version that matches all combined requirements. Since this is always the same for a given set of dependencies, I much prefer this approach. Is there a way to make npm work like this too?
To answer my own question:
npm has introduced a new command npm ci which does something similar to npm install but enforces that the specific versions are used that were also used when a package was initially added by using the package-lock file.
See https://docs.npmjs.com/cli/ci for more information
I'm trying to create patches using the method from this tutorial. An issue I'm running into is that I can't install a new patch on top of a previous patch.
I can full install Version A,then patch to Version B. After that I can't patch to Version C.
I can full install Version B, then patch to Version C.
Currently we just do full installs with major updates each time which is working fine, but because of the frequency of our (internal) updates the file size and update time is becoming a burden so we're looking to reduce the update time (both downloading and installing) especially when most of the files don't change.
Edit: Another requirement is that at any given time a full install can be done instead of a patch. The solution I came up with setting a static product code made full installs on top (without manually uninstalling) doesn't work.
If you're not doing a major upgrade, but you are changing versions, you're doing a minor upgrade. To be able to install the next version .msi file over an existing installed previous version, you're going to have to set REINSTALL to a list of modified features somewhere (or to ALL if you're lazy and willing to put up with Windows Installer doing extra work). Often setting REINSTALL handled by the bootstrap, but it is possible to set it in the .msi and reset it to empty ({})when the previous versions are not installed (condition Not Installed).
Looks like the issue was that I was previously making all upgrades major upgrades, but that's not supported with patching. Changing to a static product code rather than auto-generate fixed it.
Edit:
Looks like it solved the first problem of Install A Patch B Patch C not working, but now trying to do a full install of D on top doesn't work.