It's been a while since I last updated one of my modules in the Raku ecosystem. Do I need to update a central registry file/repo or will the update be automatically detected?
After I bumped the version number I waited for an hour or so and then zef could install the module - thanks fo the comments above. It looks like the ecosystem automatically picks up changes.
Related
The answer seems like 'no' but I wanted to check with colleagues here.
We provide an npm package for our own sites as well as some 3rd party sites.
There's a fairly heavy and old homegrown npm package that we also have in our package.
We don't need that package any longer on our sites but the 3rd party sites do.
We also have no way of controlling the code on those 3rd party sites so we need to keep the deployed bundle name and location the same for them.
Is there a way to publish a version of our package first without the extra package for us and then a version with it for the third parties from the same repository?
ourpackage-new.js (without the dependency)
ourpackage.js (with the dependency)
I had some success with a new package json in a subdirectory. I would create a new package and the original package via a command in gitlab.yaml to cd into that directory and npm publish there after the first one. This requires copying some dependency files down there as well which would mean if one version was updated, we'd need to remember to update the copy. Not a situation we'd want.
Even if we created a 2nd repository for the change just for us, we'd still need to update 2 repositories every time we had a new change to deploy.
Checked into Aliasing as well, we wouldn't be planning to import a new version and an old version though, more like sister versions.
In any case, thanks for the input and thoughts. I realize Npm was prob not made for this type of situation. If I remember right, I could do this with Gulp years ago, but I haven't even thought about Gulp in so long :) And then, I'd have to deploy manually via an FTP program ... wow, those were days.
Thanks again!
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.
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.
For example I have Intellij Idea installed on my Arch Linux system. Intellij Idea has built in updater and assume that I's already updated Intellij Idea with that built in Intellij Idea updater. But when I perform "yaourt -Syu" corresponding Intellij Idea's package is still shown in list of packages that are waiting for updates. So how can I say yaourt or pacman (or any other pacman wrapper that may have such feature) that package is already updated?
If you just want that Feature I would recommend yay to you, it has that Feature to skip an installation of a Packet! As discussed here you shouldn't use yaourt anymore.
If you don't want that update Problem at all install jetbrains-toolbox which will manage your installed IDEs, if you are using more than one, so you only have to update the toolbox once in a while.
The problem is that you haven't updated it. You've overwritten the copy pacman knows about, with an untracked copy from elsewhere.
So, of course, pacman's metadata will not be updated. In order to circumvent this you'd need to create a custom dummy package which provides intellij, while managing it entirely yourself.
But what is wrong with using the official repository package https://www.archlinux.org/packages/?name=intellij-idea-community-edition and just letting pacman update it for you?
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.