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"
]
}
Related
Turns out you can't have comments in JSON files, and it's a bit awkward to have people refer to some documentation telling them what line to copy/paste in and where in order to achieve this.
I think I can make a python script to copy/paste in one of two package.json files depending on what flags they pass in, but that feels overcomplicated.
I think I can include both dependencies (under different names) but that would create a requirement for both to be available, which is not good either.
Looking for ideas/thoughts on a good way to accomplish this. I have a release and dev version of the same dependency and I often need to swap between the two. Would like to improve the workflow beyond just having a notepad on the side with the two lines pasted in it...
yarn and npm already do this job, why not use them?
Releases
Tag the dev versions when you release them
yarn publish --tag dev dep
npm publish --tag dev dep
Then reference the tag at install time yarn install dep#dev.
Local
For local dependencies, npm and yarn provide the "link" command.
In your dependency dir run yarn link
In you project dir run yarn link dep
You could document the commands as scripts so easy to run or view.
"scripts" : {
"dep:local": "yarn link dep",
"dep:dev": "yarn install dep#dev",
"dep:latest": "yarn install dep#latest"
}
I wanted to install jquery and found instructions here:
http://aurelia.io/hub.html#/doc/article/aurelia/framework/latest/contact-manager-tutorial/4
I then wanted to install "moment.js" and found instructions here ( I am not using typescript) :
How to import Moment-Timezone with Aurelia/Typescript
To install both of these with the Aurelia CLI the procedure is to install the respective npm module and then to manually modify aurelia.json in some way so the app recognizes it.
In the case of moments the instructions then say to place an import at the top of app.js , but this is not the case for JQuery.
First off , is there any way the changes to aurelia.json can be automated ( like a regular node.js package.json) so I don't need to manually do it and second, how do I know what modifications I am expected to make to aurelia.json ( or app.js or any other file) for the module I want to install?
With a basic node.js app its pretty simple , just npm install. With Aurelia its much more confusing.
Edit: There is also JSPM which I've read is used for front end libraries like the ones I mentioned above. However, the links with instructions for installation that I posted are not using JSPM.
Edit
I found some of the answers here:
http://aurelia.io/hub.html#/doc/article/aurelia/framework/latest/the-aurelia-cli/6
The CLI is still under development. I think the automatic adding of a package might some day be included in the CLI itself, for example with an install command.
The extra registration is required to register the package correctly for usage with RequireJS (http://requirejs.org/). And if the plugin exists of more than just 1 file, this registration is a bit more complex then just adding the name of the plugin.
There is an experimental CLI task here https://github.com/martonsagi/aurelia-cli-pacman that will do the automation for you.
Which can be installed by running:
npm install aurelia-cli-pacman -D
The above will install the package manager and register/ include itself in the tasks in your current project (be sure to run it with install, because npm won't run the post install script if you run it the i shorthand). Next, you can run the following command to install an extension:
npm i aurelia-interactjs -S
au pacman i aurelia-interactjs
The only downside for many might be that currently there aren't that many registry entries, but I think the author of the package would be very happy if you help him out by creating a pull to extend the registry. Would take you some time to figure out what would be the correct install/ import settings, but you will help out someone else and make them happy when they hit the same problem you experience :-).
JSPM has a same sort of issue around this, only is more matured/ the registry is bigger and/ or authors added specific information for JSPM installations to their package.json. For example: To install the above plugin with JSPM it will use the following highlighted section https://github.com/eriklieben/aurelia-interactjs/blob/master/package.json#L72,L86. The same is currently not possible with aurelia-cli, because the installation is done by NPM instead of through JSPM that redirects it to NPM.
If the author of the plugin didn't specify the JSPM section in the package.json, you would most likely and up with the same sort of issues. JSPM has a similar registry (https://github.com/jspm/registry/tree/master/package-overrides/npm) as aurelia-cli-pacman.
TL;DR:
My project has dependency of "dep": "snapshot" where 'snapshot' is a tag. Running npm install does not fetch new version of "dep".
Full story:
So just recently I started with a JS project, and... to make a long story short i setup my own private repo via a locally installed Nexus.
Let's call my project myProj1.
I added the Nexus registry in my .npmrc like so:
registry=http://nexus:8081/nexus/content/groups/npm-all/
All is fine, I try and release snapshot versions before i release any production ready code.
This includes running npm-snapshot X where X is my snapshot number. (It's basically a plugin that changes the package.json version tag to something like 1.0.0-SNAPSHOT.24 (if X = 24)
I then run
npm publish --tag=snapshot --registry=http://nexus:8081/nexus/content/npm-internal
and it pushes the code to my Nexus, and all seems fine. The tag "snapshot" in my nexus registry is updated to the recently published version. (1.0.0-SNAPSHOT.24)
I then have another project which has a dependency on the above module in it's package.json specified as such:
"dependencies": {
"myProj1": "snapshot"
}
So I run npm install in the project root, and lo' and behold, the dependency get's downloaded perfectly, everything is awesome!
Now here comes my issue:
I then decide to update some stuff in myProj1, making me release another snapshot version with the same command above. (causing the newly published artifact to be versioned 1.0.0-SNAPSHOT.25) My Nexus is awesome and publishes the new dependency like it should, also updating the dist-tag "snapshot" to the newly built version.
HOWEVER, when i run npm install from my other project, believing I should be getting a newer version of myProj1, nothing happens. It doesn't fetch the newer snapshot version. Why's that?
Have I misunderstood having a dependency on a dist-tag? Can I do this some other way?
Regards
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
Sometimes it's useful to rebuild an entire site and force bower to reinstall new versions of all the packages in bower.json.
However, there doesn't seem to be any way of doing that:
Attempt #1:
$ bower uninstall
bower not-installed 0
Nope, that only works on a package-by-package basis, even though a clean 'bower install' uses bower.json.
Attempt #2:
$ bower install -f -l 0
$
Nope, despite '-f', this does absolutely nothing if the dependencies are met.
Attempt #3:
$ rm -r bower_components
$
! Ah victory! ... wait, what's this?
rm: bower_components: No such file or directory
Oh darn, there's a .bowrc in this project that sets the directory to install things to.
My current terrible solution:
Run custom script that:
- Parse .bowerrc if one exists
- Load the directory if one is specified in the json block
- If the directory currently exists...
- ...recursively delete the directory.
It works, I suppose, but it's pretty annoying to have to setup repeatedly.
Am I missing something?
Is there not just a simple bower command to delete the local installed modules?
Seems like really basic functionality I would expect bower uninstall to do.
(This isn't really a very javascript question, but I'll happily accept something that hooks into the bower module somehow to make this happen in a simple node script)
Context
Edit: If you want 'motivation' for such a task, it's this: We have a jenkins server that builds our projects and runs tests. However, periodically it fails for no obvious reason; investigating, it's almost always because jenkins is using a previous copy of the repository with just a git-pull to update to the most recent version before building and running tests; as a result, the previous bower_components directory is there, and it is full of cached copies of the various components.
Here a few example of things which are ##$##$'d and require bower to be run again as a forced install:
1) Some idiot (>_> fitvids) deletes the previous tagged release of a project.
2) Some project has dropped off of bower / moved its github page
3) Some project (>_> jquery) has changed the way the files are laid out in a non-major version revision.
I realize that the 'correct' solution to this problem is: fix jenkins so it creates a new temporary directory for each build. ...but that's not in my control.
So, as a build step, I need to automate a way to delete the bower components and force them to all be reinstalled; either as a grunt task (part of the build) or a jenkins build step. However, remember from (3) above, that our projects use .bowerrc, so it's not as simple as simply deleting a folder.
It would be great if I could uninstall all the existing bower components as a pre-build step to make this work.
So... back to the question: Can this be done with bower?
Updated Answer
If you're trying to update all of your packages, use
$ bower update
Original Answer
Go to your bower.json file and remove all of the components, or libraries, that you want to uninstall from devDependencies.
After you have removed the ones you want gone, execute -
$ bower prune
start with -
"devDependencies": {
"angular": "~1.2.15",
"angular-ui-router": "~0.2.10",
"moment": "~2.5.1"
}
remove angular references from file -
"devDependencies": {
"moment": "~2.5.1"
}
execute
$ bower prune
watch your angular dependencies get uninstalled
how about
edit the bower.json
'rm -Rf bower_components/*'
bower install
I was trying to upgrade to polymer 0.2.4 from 0.2.3. I can't seem to find a quick way to uninstall a set of dependencies. So I just manually removed those polymer* dir under bower_components. But for some reason bower kept remembering I had 0.2.3 installed event with bower.json modified. A 'rm -Rf bower_component/*' seems to do the tricks.
Actually I do something a little bit tricky but it works for me:
for package in $(ls your_bower_components_folder); do bower uninstall "$package"; done;
bower install
Uninstalling Packages
To remove a package you can use the uninstall command followed by the name of the package you wish to remove.
bower uninstall
It’s possible to remove multiple packages at once by listing the package names.
bower uninstall jquery modernizr sass-bootstrap
Adapting Jumar Polanco's answer to use it in Powershell, it is possible to programmatically uninstall bower components in the following way:
In the Powershell interface, navigate to the location where bower.json and the bower_components folder is located. Usually is the root app folder.
Then you can run:
foreach($package in ls bower_components){bower uninstall $package}
Depending on what the packages dependencies are, it may be required to pay extra attention to the process, as some prompts which require extra input (Y/n) to continue the process may arise (such as dependency conflicts).
I don't know what build tools you use, but if it includes Grunt with grunt-bowercopy, you could use the clean option. It removes the bower_components folder (or whatever you've configured it to use) after copying out the required files.
Ideally, I'd prefer something that didn't require me to re-download all the dependencies with each build, but just the ones where doing a fresh install would find a newer version.
I'm looking for a better solution to this as well, so I'll update if I find one.
I've been using nombom to do this (as a bonus, it also re-installs your npm packages from scratch):
https://www.npmjs.com/package/nombom
This is what ended up working for me via Windows cmd prompt:
forfiles /p .\bower_components /c "cmd /c cd .. && bower uninstall #fname"