I am using semantic-release with travis CI to automatically publish my package. I have two question:
My version has automatically been upgraded to v1.0.0. I want it to be something like v1.0.0-development. How can I do that?
Why my github's package.json's version not same as what has been published to npm?
My version has automatically been upgraded to v1.0.0. I want it to be something like v1.0.0-development. How can I do that?
You can't because v1.0.0-development is not a valid semantic version. Once https://github.com/semantic-release/semantic-release/issues/563 is released you will be able to use pre-release version (like v1.0.0-development.1).
Why my github's package.json's version not same as what has been published to npm?
See the first entry in the FAQ: https://semantic-release.gitbook.io/semantic-release/support/faq#why-is-the-package-jsons-version-not-updated-in-my-repository
Related
We have a monorepo setup (using lerna) to handle multiple packages. Now when some updates are made to certain packages, the version number are bumped up and published via a jenkins job that also commits back the updated version no. to the branch that was used to run the jenkins build with.
The issue we're currently facing is that when a new version is published from a certain branch say "feature/A", it would update the version of that same package from 1.0.0 to 1.0.1 in this branch. But all the other branches are still at version 1.0.0, and if a user B with branch "feature/B" tries to run a the same publish jenkins job, they see an error stating that version 1.0.1 already exists and so the publish fails.
So we're looking for a way that allows the user to run a local script or lerna command on their branch "feature/B" locally that pulls the latest version from registry and updates the version in local their to 1.0.1, so that when user B pushes this code and runs the publish job, he is able to publish 1.0.2 successfully.
An equally helpful solution would be if somehow we can ask lerna to skip already existing package version nos and just publish the next version no. i.e skip for 1.0.1 and directly go to publish 1.0.2.
Similar question to - How to manage canary version bump in monorepo with lerna from different branches
We are currently manually updating the package version nos locally when we encounter this issue which isn't ideal and we would like to automate this.
In my project, I have some outdated dependencies that have been flagged by Checkmarx.
However, the dependencies flagged are in react-scripts version 4.0.3. For example, there are packages flagged within react-scripts, i.e ejs, immer, url-parse, debug and some more.
What would be the best way to upgrade these packages, individually or update to the latest react-scripts version, would that solve it?
I'm Ravid, a security researcher in Checkmarx.
Please allow me to address your question.
The best way to work around this issue is to update the "root" (react-scripts in this case) to the latest version.
Once you will update this package to its latest version (5.0.1), the transitive dependencies (AKA the children) will get updated accordingly.
For example, react-scripts uses react-dev-utils which uses immer, once updating react-scripts to the latest, you will notice it uses the latest version of immer.
Please note that a project might use a few different versions of the same package.
For example, react-scripts (latest) uses debug in versions 4.3.4 (latest) as well as 2.69 and 3.27.
It is important to remember then even after updating the "root" package there might still be outdated "children" packages, since some packages are still using vulnerable/outdated package versions.
An example of that would be:
As you can see, react-scripts (latest) uses webpack-dev-server (latest) which uses portfinder (latest) which uses debug 3.2.7 (NOT latest)
The "problem" relies on portfinder, which does not uses the latest version of debug.
Regarding breaking code after updating the dependencies, Checkmarx have an engine that will alert the method, line, and file that was broken At the moment, this feature is internal only but should be production-ready soon enough
A npm package has old versions like 1.0.3 and new versions like 2.1.2, I found there is a bug at version 1.0.3, so I need to fix it and publish a new version 1.0.4, so I need to get the code of 1.0.3, but I found that there is no tag at the git repository, so how to do with this?
We have a project that has a dependency that always needs to be the latest beta build from an npm library. Unfortunately, there are -dev builds in there as well.
For example, there could be the following versions in the "x-library".
"1.2.3-dev.294 // published today
"1.2.3-beta.123" // <--- the one we want published yesterday
"1.2.3-dev.293" // published a week ago
"1.2.3-beta.122" // published a month ago
Is it possible to get the latest 'beta' build automatically in a package.json like so:
devDependencies: {
...
"x-library": "latest-beta" // just for clarity
}
I don't think this functionality is available through npm. There's not even the possibility of using regex to define your dependency version currently.
You could cobble together a solution yourself. Make a bash script update-and-install.sh using these pieces:
get JSON with all available versions
npm show my-package versions --json
filter the JSON to get beta versions only
use the package semver-parser and its method compareSemVer to sort for the latest of those betas
use sed to edit your package.json to set the dependency to the desired version
run npm install
Don't know if that's helpful, but that's what I would try if this were a project requirement. Good luck!
I'm using angular-ui-grid 4.0.2 (the latest version) in my project.
According to the documentation here:
http://ui-grid.info/docs/#/tutorial/403_end_to_end_testing.
There should be some sort of test utilities module available named something like 'gridObjectTestUtils.spec.js' in a folder named 'e2e'.
As far as I can see no such module exists.
Here is a link to the source:
https://github.com/angular-ui/ui-grid.info/tree/gh-pages/release/4.0.2
Does anybody know if the testing module is still available? Or has it been deprecated?
I was using: https://mvnrepository.com/artifact/org.webjars.bower/angular-ui-grid which is the same artifact you get from running:
npm install angular-ui-grid
This package (for whatever reason) does not contain the test utilities.
However if you use:
npm install angular-ui/ui-grid (unfortunately not available as a webjar)
You get the e2e folder with all the test utils inside!
By the way, I have checked and ui-grid is the same thing as angular-ui-grid.
Also, ui-grid has it's latest commit set in this month of 2017, so it's not an older version. If you want to get the testing utilities, make sure you download ui-grid!