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.
Related
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.
I've recently installed some npm package (recommended Kubernetes client) for my react app.
After writing code that uses the package and deploying the code for testing I got some weird errors about missing functions or packages. Then I've read the documentation and realized that the package was Node-only.
Is there any way to check that the npm package works in browser before writing code that uses the package?
Python packages specify compatible python versions. Do npm packages have something like this whether they indicate support for particular Node versions and the browsers?
Some packages/libraries contain .browserlistrc file which I've found to be a starting point to find out the browsers and platforms the devs intend to support or have their code compile for. While it may not always be true and the package might just be able to support a browser that isn't mentioned, it's a good starting point. It surely helps to find out if IE (the bane of front-end dev) is supported or not.
Then again many packages don't necessarily include a .browserlistrc. You can then check the package.json for a "browserslist" field.
If neither are found, you can always clone the repo and add your own .browserlistrc in the root with queries that will let you know if the package supports your intended browser or platform - little more work but yeah it can help. Not full proof but a decent enough way to find out.
Though the best answer is really to just ask the maintainers.
Is there a best way to publish a previous major version of an npm package without adding a tag for it? Our current major version is 3.x (v3) so we npm publish that version to automatically give it the latest tag. When we publish updates to the 2.x version (v2) we have to give it a tag so that it doesn't automatically grab the latest tag from v3.
We could do something like previous, though the meaning of that is subjective. Really we don't need a tag for v2 at all. Semver works great if people want to install v2. Is there a better solution to not add unnecessary tags than publishing it with a tag and adding a postpublish script that deletes the tag? (That sounds ridiculous as I write it)
Looking at this comment from 2015, "Every publish must be associated with a dist-tag, by design." And I don't see a way to bypass the tag in the current code of libnpmpublish and npm, unfortunately.
Thus, I think you have the best options laid out already: publish under another tag, whether that tag is temporary or not.
However, if I could make a suggestion...
Instead of the subjective previous tag, you could consider publishing the previous versions under a tag called v2. This is a pattern that I've noticed the Angular team uses for LTS releases, for example:
While I think it's of minimal use to a consumer since they could just npm install #angular/core#11 instead of npm install #angular/core#v11-lts, nonetheless it might be a cleaner approach to publish.
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.
My standard route has been to go to confluence, find the docs sections, then navigate through to the install docs for the version, e.g. sakai 10:
https://confluence.sakaiproject.org/x/iYGLBQ
Through one means or another I happened across the source route to this too, so starting here....
http://source.sakaiproject.org/release/
You get redirected to the latest stuff, and appended version numbers to that url gives you other docs, e.g. adding 2.8.2 or 10 to the end of the url
But the links to what I should download are quite often not there, at the time of writing the 10 tar ball and zip in the confluence links are dead and the source.sakaiproject links doesn't have the 10 docs yet (redirects to 2.9.3) presumably this is because v10 is not released yet....
So, I'd like to evaluate a new version of a sakai source install, what's the best way to do this? (considering the official documentation for install is still being formed)
Do I download the latest SVN, or the latest RC or the latest beta or??? How do I know what's best to test against without being "too" bleeding edge? Is there a recommended tar ball/zip link to test against? Is there a "latest good" SVN branch?
The latest code is always in the Sakai trunk (currently svn):
https://source.sakaiproject.org/svn/sakai/trunk/
That code may very well not be stable though as it is where things are being actively developed. If you are not actively developing then you should stick to the releases as indicated on the project website here:
http://sakaiproject.org/current-release
If you want to use something in between (say an upcoming release) then you can grab the most recent tag or maybe use a recent branch (both currently in svn, latest shown below at the time I write this):
https://source.sakaiproject.org/svn/sakai/branches/sakai-10.x/
https://source.sakaiproject.org/svn/sakai/tags/sakai-10-rc02/
The reality of the situation is that if you want to use something other than the release then you should really participate in the dev community for Sakai. Joining the mailing lists and the weekly calls will provide the information you are asking about and much more.