I'm introducing unit testing in my project and for this, I need to make myself a package.json file.
First question is, which unit testing suite are you using? I'm looking forward mocha which seem to be pretty much standard for Node.js projects.
Second question is: Is there any magical way of generating a package.json file? (for dependencies and versions)
Third question is: I've been testing a lot of npm packages while developing my project and now I'm stuck with a lot of probably unused packages. Is there any way to tell which one are useless? (I saw npm list installed which is useful though)
I am using Mocha.
npm init
npm ls will list "extraneous" next to ones that are not in your package.json. But, it sounds like you don't have a package.json yet.
Basically, your workflow is very backward. Here is how it is intended to work:
Start a new project with npm init. It has no dependencies.
Oh, I want to start using a package, say express? Add it to package.json under dependencies, then run npm install.
Oh, I want to start using a package for development, say mocha? Add it to package.json under devDependencies, then run npm install.
You seem to have some existing code with manually-installed packages (via npm install <packageName>), which is a mess. I suggest starting over and following the above workflow.
To answer the third question:
npm prune
will remove all installed modules that are no longer mentioned in your package.json.
And you should really have asked 3 separate questions.
I am also using Mocha. It has code coverage, BDD, TDD, runs in browser. It is pretty complete and also heavily maintained by I think one of the most brilliant javascript/node.js programmers named TJ.
It is almost impossible to guess which version(s) to use. Because npm does not know which version breaks which dependencies. You could probably install all dependencies using something like node-detective. Then you can just install them using npm.js from within javascript. Maybe I would like to tackle this in the future.
I would also probably delete all dependencies , next install needed dependencies back using step(2). But also disc-space is not such a big case anymore with the current HDs.
P.S: I think I also agree with Domenic
I am using vows. It's pretty good, but not perfect. I have found unit testing in node to often be challenging because of async callbacks to dbs & such, and have mostly been testing top level functionality.
Here's your magic: Managing Node.js Dependencies with Shrinkwrap.
The only way to know what packages you are using is to know. You can't generate this programmatically. My advice would be to remove packages aggressively, then retest all functionality - if it breaks, you'll know you need to reinstall one of your packages.
Answering your third question, you can use Sweeper to list unused dependencies, and them remove them from your package.json. Just npm install -g sweeper then on your project directory call sweeper on the command line.
Related
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.
In the projects prarent directory, if I do,
npm init
a file "package.json" is created,
Now if I want to install dependencies like let's say angular, jQuery and bootstrap I can do
npm install angular --save-dev
npm install jquery --save-dev
npm install bootstrap --save-dev
a folder "node_modules" get created, with the above mentioned dependencies.
and the same entries of dependencies in entered in "package.json" .
Now using any build tool like lets say gulp.js,
I can inject the "node_module" dependencies in my SPA's(Single page application) index.html.
So my question is, why to use Bower ?
Please let me know with some pointers
Short answer: Don't (use bower).
Bower started as a "clone" of npm for the client-side, but meanwhile literally everybody is using npm for this, too.
So there is no need to use bower any more, just rely on npm, and everything is fine. It makes your development workflow simpler, more unified, and you just end up with less friction and complexity (which is a good thing).
My biggest concern with bower is that it introduces unneeded overhead, such as another tool, another configuration file, another way of dealing with versions, another folder where modules go to, … I have hardly seen any benefit of bower that outweighs these drawbacks. Again: Just stick to npm and you're fine.
I myself thought of this just yesterday.
From my experience, you can be well off with just npm, provided the packages you need are registered.
This was not the case a few years ago, but now it nearly mirrors bower's repository.
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
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
I've noticed that in trying to get seemingly simple node packages to install with npm (e.g. nerve, a "micro-framework") I often run into some form of dependency pain. After some digging, I tracked down the problem with nerve to the bcrypt module, which is apparently written in C/C++ and has to be compiled after the package manager downloads it.
Unfortunately, it seems like if you want this to work on Windows, the answer is (from one of the bcrypt issues threads) "install a Linux VM". So earlier today I did just that, and started running into other dependencies (you need certain unnamed apt packages installed before you can even think about building, despite GCC being installed), then eventually after seeing yet another C compiler error (about some package or other not being able to find "Arrays.c" I think), I actually gave up, and switched from nerve to express instead. Ironically, the larger and more complicated express installs with npm on Linux and Windows without a single issue.
So, my question is: is there any filter / dependency tracking available that lets you see if a package has additional dependencies besides node core? Because to me the allure of node is "everything in Javascript", and this kind of stuff dispels the illusion quite unpleasantly. In fact, despite having done more than my time working with C/C++, whenever I see a requirement to "make" something these days I generally run in the other direction screaming. :)
The first solution doesn't tell you if a dependency makes the package impure or not. Much better to search for gyp generated output:
find node_modules/ | grep binding.gyp || echo pure
Look out for the "scripts" field in the package.json.
If it contains something like
"scripts": {
"install": "make build",
}
and a Makefile in the root directory, there's a good possibility that the package has some native module which would have to be compiled and built. Many packages include a Makefile only to compile tests.
This check on the package documents does not exclude the possibility that some dependency will have to be compiled and built. That would mean repeating this process for each dependency in the package.json, their dependencies and so on.
That said many modules have been updated to install, without build on Windows, express for one. However that cannot be assured of all packages.
Using a Linux VM seems to be the best alternative. Developing Node.js applications on Window gives you step by step instructions on installing a VM, Node.js and Express.
Node is not "everything javascript" , since one way to extend node core is to write c/c++ plugins.
So Node is more a javascript wrapper around c/c++ modules using V8.
How could you write efficient database drivers in pure javascript for instance ? it would be possible but slow.
as for the filters , it is up to the author to document his package. there is no automatic filter.