I have a private npm package that is currently published to npm. The maintainer before me did not consider automated versioning, and the version is 1.0.58.
I have installed semantic-release and a small GitHub app that can be found here: https://github.com/zeke/semantic-pull-requests
My Github Action is setup properly, because when I push to main, the process goes through and reach the publishing step. However, the tags that are created started at 1.0.0, then 1.0.1, etc.
I tried creating a tag manually on the main branch at the latest merge, that tag is v1.0.58, but when I publish again, the tag that is created is still 1.0.2, etc. As such, I get an error message that says I can't publish "over" the current version.
How do I go the 1.0.59 with a fix:... commit?
Thanks everyone!
Forgot to post solution...
It seems Semantic Pull Requests did not have a proper starting point as the initial tag was created after it was linked to the repository. Uninstalling Semantic Pull Requests, adding the latest tag (corresponding to current version of published npm package) manually and reinstalling Semantic Pull Requests caused to process to go through flawlessly with semantic-release.
Related
We have a React App which uses some components written by us and published to our internal npm repository. Our code is maintained in Bitbucket Data Center, the build is done with Bamboo and the npm repository is hosted in JFrog Artifactory. We work with feature branches and pull requests for developing new features.
It happens often that a new feature in the app, requires a change in the component. In this case, each repository (the App and the component) will have its own feature branch and pull request. Many times the component interface changes, so that the App needs the pull request version of the component and not the mainline one to build and to be tested.
The build is done exclusively by the build server, so that the bundled javascript files are not committed to git.
Let's say the component has version 1.0.0. A new feature in the App needs a change in the component. In this case, the component version will incremented to 1.0.1. We don't want to publish it to Artifactory, until version 1.0.1 is tested, but at the same time, the build of the new App version needs the changes from version 1.0.1.
Our current solution is to change the package version of the component during the build of feature branches to something like 0.<Ticket #>.<Build #>. This 0.x.x version will be published to Artifactory so that the App feature branch can use it to compile.
We use 0.x.x so that the version is never bigger than the current released version. Once the component is merged to the main branch, it will compile with the right version (1.0.1) and will be published to Artifactory again.
I find this solution cumbersome, it requires some funny build scripts, making sure that the branch name always follows some convention and teaching developers about it.
I wonder if there is a better way for managing pull requests and feature branches using npm, without having to manipulate the package.json during build time, depending if it is a feature branch or the main branch.
Sounds like you are using artifactory like a secondary version / staging for the npm package, just use npm?
I am not in devops, but have worked on a few packages, testing a package that has not been released does not sound like testing the package - what about using a beta tag npm publish --tag beta, pulling that into your app npm i package#beta then testing your application in a staging environment?
As i expect you know if you apply a tag then the tag would need to be specified to be pulled into a repo so you can use it to deter users from using that version of the package - an i believe you can delete versions later if you are dead set on not having it public.
Here is a medium article which may be helpful?
I'm using the semantic-release package which runs on my CI to release my library onto npm through my Github repo.
Recently, I have a breaking change that I have forgotten to add the breaking change text into my commit message before merging. So semantic-release made a minor release and published it onto npm instead of a major release.
Can I simply remove the wrong release created by semantic-release on Github to unpublish it?
How can I undo and unpublish the wrong minor release on Github and npm, and get semantic-release to re-release the recent commit I've made as a major release without messing up my repo?
You will have to remove everything manually.
Please note, once an NPM package has been published to the default npm registry, it can be unpublished within 24 hours (I may be off), but there is a catch, trying to publish the same version again will not work, the registry will block you.
So in case you remove the Git tag created by semantic-release, and the next version is the same as the unpublished one, you're in trouble.
I can also recommend using an alternative to semantic-release
called atomic-release.
It's an SDK with a strategy to release NPM packages (kind of like semantic-release). Check it out GithubNpmPackageStrategy
Disclaimer: I'm the author of atomic-release.
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.
I need to create a custom version of Dygraph which I will be installing directly from my fork's Github repo (using npm). My question is:
How do I generate the files that are generated by a regular Dygraphs npm install? Such as dygraphs-combined-dev? I don't see them generated by npm run build.
Hope i'm being clear...
Thanks,
Uri
Sorry, my answer is largely speculative from reading the commit history in the GitHub repository.
The latest stable release (1.1.1) was in June 2015, but the build process was overhauled in October 2015. It seems likely that dygraph-combined-dev.js and dygraph-combined.js will be renamed in the next stable release to dygraph.js and dygraph.min.js.
As per the documentation, by calling npm run build you will generate these files in to the dist folder.
If you need compatibility with the previous names, you may need to modify scripts/build.sh to rename these files appropriately.