CODEWITHSUNDEEP
gitnode.jsgithubnpm
flow
flow

Reputation: 3652

nodejs, github, npm, and symbolic links

i have a nodejs project with a few dependencies on my own modules. as per npm's current best practices, those dependencies are represented using the npm link/npm link $package-name commands, so the project now has some symbolic links in its node_modules. locally that works.

however when i push that project to github, the links are preserved as links, meaning that other people that clone it will (very likely) see broken links. another point is that i push the node_modules directory to github at all—that's ok in so far cloning from github now gives you a complete instance of the project with all dependencies resolved, but on the other hand i suddenly have a lot of 3rd party stuff in my repo.

what is the best practice to deal with this kind of situation?

edit one thing i just realized is that checking in dependencies as installed code is wrong anyhow—there might be some binaries involved that need to get installed in a platform-specific way. so you never check in your dependencies?

Upvotes: 2

Views: 1531

Answers (2)

Mulan
Mulan

Reputation: 135377

First, do not include other node modules in your git project

cd ~/your_module && echo "/node_modules" >> .gitignore

Second, if your module has dependencies, just declare them in your package.json. Here's an example from my burro module

// package.json
{
  // ...
  "devDependencies": {
    "mocha": "~1.8.1",
    "hiccup": "~0.1.4"
  },
  "dependencies": {
    "bun": "~0.0.5"
  }
}

For what it's worth, I do not actually use the npm link feature; I build/test all of my modules separately. There's a good handful of them you can see on my github repositories if you want other examples.

My basic workflow is this:

  1. patch module A
  2. bump version on module A
  3. npm publish module A
  4. bump version dependency of module A in module B
  5. re-npm install module A in module B
  6. patch module B to work with new version of module A (if required)
  7. bump version on module B
  8. npm publish module B

npm link is handy, but I think it enables/encourages too tight of a coupling between your modules. I firmly believe the "do one thing and do it well" mantra and keep this in mind when authoring all of my modules. Using this workflow will help keep your functionality well-encapsulated and the community will love your releases.

As for the github bit, npm doesn't really care about this. As a habit, before I npm publish a release, I will always tag that commit with the module version. Here's an example

  1. set version to "0.1.5" in package.json
  2. git commit -m "bump to version 0.1.5"
  3. git tag v0.1.5
  4. git push origin master --tags
  5. npm publish

Now both npmjs.org and github.com both agree on the same version. Users downloading your package from either source will always get the same thing.

Upvotes: 2

Peter Lyons
Peter Lyons

Reputation: 146084

Do not include the node_modules directory in your source repository. Git is for source code, not built distributions. That is the best practice as it has been for decades. Ignore the hipsters you see occasionally putting build artifacts into git. They are wrong, they just haven't felt the pain enough yet to realize it. Besides just being incorrect from a sound methodology perspective, including your node_modules in git will fail when (not if) your project includes any extensions with C components that are compiled per-platform. This will fail requiring at least an npm rebuild by the user who cloned the repo to fix it, and at that point you might as well just have them do the npm install as $Deity intended.

Upvotes: 2

Related Questions