We Keep Coding

Develop a npm package based on old version code

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?

angular-ui-grid - no gridTestUtils.spec.js

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!

Generate changelog for a semantically released package

Here is the package I'm working on currently.
This is the first time I'm trying to enforce the conventional changelog format and use semantic release versioning. The releasing itself works fine, I'm having travis CI testing, building and publishing the package to npm, creating a new version and a git tag. There is also a GitHub package release created, which is, in a way, a replacement for a separate changelog file.
What I'm trying to achieve next is to automatically generate the ChangeLog based on the latest release changes. From what I understand conventional-changelog can help with that, but whenever I run:
$ conventional-changelog -p eslint-plugin-protractor -i CHANGELOG.md -w -r 0
I'm getting all the changes grouped under the 0.0.0-semantically-released version, which is the stub version I put into the package.json to avoid warnings during npm install.
What am I doing wrong and how can I generate logs for every semantic release version?

It is working fine for me when I run the following command in your project folder:
conventional-changelog -p eslint-plugin-protractor -i CHANGELOG.md -s -r 0
I have added the contents of the generated CHANGELOG.md to a gist.
Maybe there was a bug with conventional-changelog when you opened this issue?

I think there is a semantic release plugin that does this, https://github.com/semantic-release/changelog, you'll need to add it to the release config in the publish step, or in the plugins array.

As #OAuthMan mentioned, there is a semantic-release changelog plugin and the order of plugin import is important too. Plugins will be executed in the order they are defined during the release step. This order will generate the changelog for you
{
"plugins": [
"#semantic-release/commit-analyzer",
"#semantic-release/release-notes-generator",
"#semantic-release/npm",
"#semantic-release/git"
]
}

Is bad practice to run "bower install" when deploying in production?

I am working on an application that uses bower.js; it's the first time I use bower, so please correct me if you see anything evidently wrong in my problem description.
------------------------------------------------
Coming from a Ruby background, I expect a package manager to have a .lock file, tracked under git, that tells me exactly which are the versions currently in use. This doesn't seem to happen with bower (am I right?).
A couple of days ago I deleted and re-cloned my repository, and ran bower install, thinking that such command would just install the required versions of the js components.
Then, today I did a one-line fix in a javascript file, compiled application.js using grunt watch, and realised that application.js was automatically filled up with tons of new code from bower component updates I wasn't aware of.
I found out that our bower components were under .gitignore, and that bower install, that I had run a few days ago, had actually updated two components without me noticing it.
When I realised what was happening, I immediately looked into our deployment procedure, which I paste here:
bundle install --path ${SNAP_CACHE_DIR}/.bundle
npm install -g bower grunt-cli
bower cache clean && bower install && bower list
bundle exec cap [our application name] deploy
Is this dangerous? Will bower install update all the components, that are likely not updated in my local version and are not tracked by git, ending up having completely different js code in production?

Is this dangerous? Will bower install update all the components, that are likely not updated in my local version and are not tracked by git, ending up having completely different js code in production?
Yes, this may happen and can cause problems. Although the impact will be limited as long as your dependency versions are specified as e.g. "~1.2.3", which will lock the major/minor version and only allow patch level updates.
In contrast to bower, the package manager normally used in node.js environments - npm - has a feature/command called npm shrinkwrap, which creates an npm-shrinkwrap.json file which locks down your dependency versions so that it is safe to run npm install afterwards.
This is probably what you would want.
However, bower as it stands does not have this feature yet - there is a discussion about it going on on Github e.g. here.
I think there currently are the following options to solve this problem in your situation:
Un-ignore and commit your bower_components (very ugly because of the huge amount of noise this produces in git).
Specify your dependency versions down to the patch level, e.g. "1.2.3" instead of "~1.2.3".
Culprit: If your dependencies have sub-dependencies, they might still be specified on the minor-version level, which means that even if your direct dependencies have a predictable version, your transitive dependencies may not.
Stop using bower and use npm instead (interface-/usability-wise, they are almost identical imho) and use npm shrinkwrap to lock down your dependencies.
Cheers, Alex

npm dependency management best practices

I'm a relative newcomer to the node community. I recently got on board so that I could put together a build for a complex web application that's been under development for several years. The two key tools in my build are Grunt and Browserify, but the application uses jQuery, Backbone, d3 and a smattering of other libraries and plugins as well.
A problem that I've been running into is this: by default, when I install and save a package with npm, it sets up the package with a semver expression that captures all future releases of the package whenever you run npm update. Like this article explains well, that may seem like a good thing at first ("give me this package and all future upgrades"), but it exposes your own application to any non-backwards compatible updates the package maintainer makes... The article also provides some recommended best practices, but it was written almost 4 years ago to the day; I'm hoping there are other, newer ideas.
What sort of solutions do you use to resolve this issue? I can't keep wasting time updating my software every time a breaking change is made in a library I rely on. I want to update when I am good and ready, not whenever I run npm update.

Use npm shrinkwrap to save the tree of dependencies containing the exact versions, so when you npm install it'll use those exact versions.
The npm outdated command will tell you what packages are outdated.
Instead of npm update which updates all your packages, update specific packages with npm install <pkg>#<version> --save