I have a nodejs package I wish to use - "redis-connect". This is dependent on "hiredis" but seems to be locked at 0.1.7 which does not compile. I am using 7.2.0 nodejs with npm 4.0.3 - problem with node-gyp rebuild. However, hiredis#0.5.0 compiles fine and installs. What's best practise for fixing this dependency so I can install and use redis-connect with hiredis#0.5.0?
There is no "best practice" for something like this. You just have to submit a pull request to the project and convince the maintainer to accept the PR and publish a new version afterwards.
Otherwise you will need to just fork the project and reference that fork (instead of the original project by its name on npm) in your dependencies.
Related
I am interested in understanding how to install node-sqlite3, but provide by own precompiled package of sqlite3: I just want to install the Node client and skip the build phase entirely during install.
How can I do this?
(Reasoning: I am going to test the module in multiple environments and have already read countless posts of people having build issues in various environments, so I'd rather manually compile myself.)
It turns out that I was looking for a package like this one:
dblite on npm, GitHub
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?
Let's say I've made a TDD tool called foo, and I want to use foo v1 to help me develop foo v2.
But when I npm install --save-dev foo#^1.0.0, npm says "Refusing to install foo as a dependency of itself".
Why does npm refuse to do this?
What can I do instead?
Workarounds I've got so far (and why they're not good enough):
Workaround 1: just require the relevant script directly using a relative require, e.g. require('../lib') (this is how mocha does it, and it's how I've been doing it so far).
but if you're working on a new version of your module, adding features, perhaps even removing old features, then you're constantly having to alter not just the content of your tests but also their format, because you're actually using the thing you're working on to test the thing you're working on. If it breaks, you have to fix it in the dark with no tests to guide you. It would be much better to use the settled v1 API for tdd-ing the new v2 API.
Workaround 2: publish a duplicate of your module to npm under a different name, like "foo-clone". (Then you can just install foo-clone as a devDependency of foo.)
but that seems messy and a misuse of npm. Anyway, if installing an exact clone would work, then what would be the harm in npm allowing me to install [an old version of] foo as a devDependency of foo?
Here is a better alternative to your Workaround 2.
Let's assume that you'll only need this dependency on early stage of development. So, before publishing first production-ready version you'll get rid of it, e.g. by adopting mocha solution (using current stable version to test itself).
In this case, instead of publishing duplicate package you could temporary rename your package (i.e. postfix it with -dev).
To guarantee that this renamed package will not be published, you could also add private flag.
So, your dev package.json will look something like:
{
"name": "mytdd-dev",
"version": "2.0.0-dev",
"private": true,
...
"devDependencies": {
"mytdd": "1.x.x",
...
},
...
}
Then, when your package will be ready for the first release, you'll remove all -dev postfixes, private flag and dev dependency on previous version.
The only problem with this solution is that you won't be able to publish early dev versions of your TDD tool to npm (as long as you'll depend on previous version).
if installing an exact clone would work, then what would be the harm in npm allowing me to install [an old version of] foo as a devDependency of foo
I think it's a safety precautions against circular dependencies.
If you believe that npm should make an exception for devDependencies here, which sounds reasonable to me, then you should post your suggestion to npm issues tracker.
I've encountered something in node.js that'd I'd like to submit a patch for. I've also located a Github issue in which somebody also complained about the same annoyance. The issue has been tagged saying that patches are welcome. So, I'd like to try to supply a patch.
But, what's the best way to do this? I've forked the main node repository, and I've located the spots in the C++ code that an adjustment could be made. Before I make these changes though, I am trying to figure out how to test these changes of mine. I've got the official node package installed globally. I'm on Windows. How can I test this modified version of node?
You can install node-gyp to build the addon manually (npm install node-gyp -g). Then just change to the addon's root directory and simply do node-gyp rebuild after you make changes.
After further investigation, the vcbuild.bat produces project files that can simply be opened up with Visual Studio. So, code editing and debugging can all easily be done within VS. Awesome!
It happens occasionally that the development version of a module works in my development workspace and passes on Travis-CI but after publishing to npm it turns-out the end-user package is broken.
For example if you use a sub module that should be in dependencies but had it in devDependencies then CI will pass (but there are plenty other possible breakages).
How do you automate testing this? Do you use external rigging? Is there a secret module? Do you have a user acceptance test suite?
I use Github with Travis-CI but the standard setup uses the development install.
Once upon a time I discovered that npm would let me publish packages that are uninstallable. So I've added a target to my Gruntfile that does this:
Issue npm pack to create a package from my source.
Into a directory created (automatically by my Gruntfile) just for testing install the new package using npm install <path to the package created in the previous step>.
I have a target for publishing a new version that will publish only if the steps above are successful.
The steps above would not catch the dependency problem you mentioned in the question but they could easily be extended to catch it. To do this, I'd add one or more tests that cause the package installed in step 2 above to call require with all that it depends on.
I would suggest to set up your own CI server that does essentially one thing, npm install package ; cd node_modules/package ; npm test. This would ensure that your package is installable at least on your server.
I heard that Jenkins is good for this (at least, that's what node.js core team seems to be using), but don't have any first hand experience yet. We're just planning to set in up in a couple of weeks.
Also, having some external module that depends on you and testing it helps a bit. :)