Reputation: 55937
Fundamental question: How should we use npm link in a team environment? I'm hitting a conceptual wall.
Idea appears to be simple: main project uses sub project, we use npm link to make sub project visible to main project, now changes in sub project are immediately visible without any fresh npm install.
Described in the npm docs. It's a two step process,
Explained a bit more in articles like this.
My problem: when I check my main project into git it has references to those global modules, modules global only on my machine. My colleague checks out both main and sub-project, don't they need to perform step 1 to create the global link for each sub project?
Clarification: I have made the, possibly incorrect, assumption that node_modules is checked into git. There has been debate about whether one should do that, but I had been convinced by the idea that if one is creating a product then a reproducible build needs node_modules.
This seems messy. Obviously we can script all this, but how is this supposed to work?
Upvotes: 2
Views: 1018
Reputation: 2366
How is your coworker getting your global links? Are you checking in node_modules
? You should never commit anything that's using npm link
. It's useful for local development, but not intended for git.
If you don't want to publish too often, you can make the main project use a specific git branch of the dependency rather than a published version, e.g., "jscs": "jscs-dev/node-jscs#v1.12.0"
.
If you know the relative path of the dependency, you could also add linking to the test
script or any other script in package.json
. That's what we use on our CI because we need to test our samples against the current version rather than a published module:
{
"scripts": {
"test": "cd ./some/my-dep; npm link; cd ../../; npm link my-dep; mocha test/*"
}
}
If you don't know the relative patch, you could use an environment variable and everybody who works with you has to set that variable for npm test
to work.
Upvotes: 2