There are solutions to increment the version number in different application. Cocoa apps have agvtool and maven has the maven-release-plugin which increments the version number on releases. Are there similar tools for nodejs?
I think such a tool seems excessively heavy-handed when the only thing you need to do to increment the version number in Node.js is something as simple as:
sed -i 's/0.1.2/0.2.4/' package.json
Will change the version for your Node.js package?
If you're talking about something that will deploy your code when you explicitly mark a new version, I'd be more inclined to use git hooks and write a script to detect when a git tag is created and then start the deployment process.
You could use the pre-applypatch hook to detect when a tag is being created to run the sed script listed above and run npm publish for you automatically, but again, I don't see the point of having a heavyweight tool handle all of that when it's a simple script away (and said script could be written in Node.js, too!)
I think the most correct answer is to use npm version.
For example, to increment the major version of your package:
npm version major
This will increment the major version of your package and if it is a git repository it will also commit that change and create a tag of the same name of the version.
Follow up with:
git push
git push --tags
grunt-bump provides version bumping, as well as git tagging/commit/push. There are similar packages for other build tools such as gulp-bump.
Similar functionality is also now available with npm version, but with fewer configuration options.
Related
I have a pretty common (i guess) problem. Many of my projects utilize nodejs, some for business logic, others only for some building task.
I need to have different runtimes in different projects, one of my electron apps requires node 7.10.0, a typical build suite requires node 8.x.
Now i know - i can use sudo n 7.10.0 or sudo n latest to switch the runtime globally on my computer (For those, who dont know this - have a look at "n")
Anyway, IMO this is not so convenient (some times, i need to rebuild all the modules after switching versions, often i forget to switch and so on). Is there a way of telling node which interpreter to use? Can i use a .npmrc file in a project directory to force a specific nodejs version within that subdirectory?
I searched exactly for this (npmrc node version) but was not lucky enough to find something.
Okay, i found a similar quesion:
Automatically switch to correct version of Node based on project
it seems you can install "avn" and use a .node-version file to do exactly that.
sudo npm install -g avn avn-n
avn setup
then you can create a .node-version file in your project and enter the desired version
echo 7.10.0 > .node-version
Then avn will detect that and activate the correct version
Unfortunately i get an additional permissions error. So to make this work, you need to install/configure "n" to work without sudo/root.
If you're fine with using another tool you could use nvshim.
pip install nvshim # this is all you need to do
It does not slow your shell startup or switching directories, instead moving the lookup of which node version to when you call node, npm or npx by shimming those binaries. More details in the docs.
Source, I wrote the tool.
NVM (Node Version Manager) allow us to use different versions of node quite easily on a single machine. You can have a look at here how to configure and use it.
Volta can used to manage multiple nodejs, npm or yarn versions on different projects on same machine. It's cross-platform.
For example you can run volta pin node#14 in project directory and this will set node to v14 if it exists otherwise it will download and then set it.
More information here https://docs.volta.sh/guide/
I am coming over to Go from Node.js and I am used to adding all my modules and then people just have to go npm install when cloning my package.
What is the equivalent of this with Go? I have a few imports and don't want people to have to manually install it if they use my package.
I also not sure if I create a simple Go application with just a package main if that allows people to just go get. I have really picked up on the Go way of repo sharing like Node.js
What is the equivalent of this with Go? I have a few imports and don't want people to have to manually install it if they use my package.
You don't have to do anything. People will not have to manually install the packages you import. When someone does
go get github.com/FrickeFresh/awesome
all of the dependencies you import in your awesome package will be downloaded automatically as needed.
Go get skips testing files by default, but a user can download those too by including -t:
go get -t github.com/FrickeFresh/awesome
But that's not something you need to worry about.
If you want to delve into vendoring specific versions of dependencies, there are a number of articles/tools available. The official tool is dep:
https://github.com/golang/dep
Basically you should take a look at vendoring. There exist tools that help you with versioning. Personally, I use vendetta which is just a little tool that "go gets" the referenced packages as git submodules into the vendor folder. So if anyone checks out my repo they simply do git submodule update --init --recursive. The package version can be specified as a git commit id in the respective submodule.
There also exist tools where you maintain the deps in a file, check out here.
I have a query on how others accomplish this and what, if any, the best practices are. I have an application that comprises three packages and they are setup in Bamboo for CI/CD.
The issue I am experiencing is that of how to automate the update of the package version on each build, e.g. npm version patch to bump the package version.
What I would like to know is how other accomplish these, I have thought about manually running npm version patch but that is not ideal and would be prone to errors (eg. forgetting to run this). I had also thought of adding a step in Bamboo to run npm version patch during the build but Bamboo clones the repository with out remotes and there unable to commit the change, otherwise every build would be the same version and still no better off.
An example is that we have a package which is an Electron application and when the build runs generates an MSI and .yml file for the auto updater, without incrementing the version the MSI will always be the same version and therefore the auto update would not work.
So what are the strategies for automating the version of an npm package for each build? What do others do in similar situations?
In my JavaScript applications I may be declaring a few dozen dependencies in my package.json file.
It would take a while to go through each one of those dependencies and see which version they are on.
I just want to say: use the latest major version, but not the bleeding edge.
As an example, with a tool like Git I don't usually care about taking changes at the patch-level but if a new major release comes out I will want it.
Is there a similar concept when specifying the version of a npm module?
NPM packages (theoretically) use SemVer.
In SemVer, packages get a version number of X.Y.Z.
Z indicates bug fixes. Y indicates new features without changing existing ones. X indicates a major version that breaks backwards-compatibility.
Doing npm install --save <package> will result in a version string in your package.json like ^2.3.9, which means "anything in the 2.* range greater than or equal to 2.3.9". This'll mean you get bug fixes and non-breaking new features, but you won't unexpectedly be updated to a version 3.0.0 that breaks your application.
Note: I say "theoretically" because not everyone sticks to SemVer's ideal. You may find a 2.3.9 -> 2.3.10 upgrade that breaks stuff at times. Tests are handy here.
Using npm i -S <pkg> should normally do the right thing.
A few caveats:
The above assumes if you are taking a runtime dependency on <pkg>. In installing a developer tool (like grunt) use -D or -G instead of -S.
Semantic versioning rule 9 says that publishers MAY identify pre-release versions using a suffix like -beta. Npm depends on it, so if package publisher FAILS to do it, you might take a dependency on a pre-release package without knowing it. Sophisticated npm publishers should know better, and sophisticated npm consumers should check the documentation.
A major version is '0' indicates the package is still in initial development, and the package SHOULD NOT be considered stable. (Semantic versioning rule 4.)
Consider using npm dist-tag ls <pkg> to see if there is some package-specific tag that identifies your intent better than latest. If so, use npm I -S <pkg>#<tag> to track that tag.
You can always use npm outdated to check if you dependend directly on a package with a new major release might want to consider upgrading to. It is by-design that major version upgrades do not happen automatically.
npm-installnpm-dist-tagsemantic-versioning
It seems that npm does a good job at managing the dependencies
of modules for a given project, with declarative dependency
management (in the package.json file).
I would like to go one step further, and declaratively
control which version of nodejs and npm from source control
(i.e. specifying these versions in some file that is
in the project' git repo, just like package.json)
On a freshly deployed machine, I would like to have only these steps :
1) clone a git repo of the nodejs project
2) install or update the versions of npm and nodejs
3) npm install
I woud then use this to have a single step deploy/update
probably a script that does (2) and (3) and that feeds
from a config file that is source controlled.
I'd be perfectly satisfied with a solution that only works on linux,
or even for a given flavor of linux
Take a look at what Nodejitsu does with their Package.json. In particular you will see the following lines:
"engines": {
"node": "v0.8.x"
}
Then take a look at the Node Version Manager available here. There's a reasonable write-up on basic usage here.
Given that your deploys should all have a package.json this seems like a pretty straightforward method to achieve what you're looking for. Should be a limited amount of "glue" code and it's clearly possible as Nodejitsu is doing it.