0

I asked this question about sharing code between Node apps yesterday with no answers, so now I have a more specific question instead of long-rambling one.

Is it considered a bad practice to add require paths to NODE_PATH?

As I mentioned in my previous question, I'm struggling with finding a way to share common assets between two node apps, and the only sensible solution I could come up with is using git submodules. I would place this submodule, containing common assets such as Mongoose schemas, to the both apps' root, update the files when necessary and then push 'n pull it over to the other app. It's a very simple process with no serious merging problems with the apps' own files like in the third solution I thought of in my original question.

The beauty of this structure would be that I could require those common assets with just folder/file.js instead of submodule/folder/file.js by adding the submodule path to Node's require paths. This would also mean that I could overwrite the submodule's common files with the app's own respective files (if they existed) by placing the submodule path further on the path stack, so that if a local file was found, node would require that instead of the submodule's equivalent.

But there's one tiny problem. Node's documentation has the following statement about adding require paths to NODE_PATH:

You are highly encouraged to place your dependencies locally in node_modules folders. They will be loaded faster, and more reliably.

So basically this means it's considered a bad practice and slows down the app, which I really don't want. Or does this only apply to global paths, so the submodule (which is in the app's root) wouldn't be a problem?

Community
  • 1
  • 1
Aapo Kiiso
  • 166
  • 3
  • 12

2 Answers2

2

I wouldn't recommend to add paths to NODE_PATH.

In your package.json you can link modules directly to repositories url:

"dependencies": {
  "myModels": "git+https://user:pass@github.com/myAccount/my-models.git#v0.6"
  "myTemplates": "git+ssh://github.com/myAccount/my-templates.git#v0.2"
}

As you can see you can reference tags, branches or whatever you want. You can use different versions for each application. Just update your tag, branch and npm install.

IMHO, i wouldn't use git submodules you can mess things up pretty bad. You can (accidentally) push the outer module with a reference to the submodule before actually pushing the submodule and nobody else would be able to work since they wont have those commits that are only in your machine). Also, submodules are always checked out in detached HEAD mode and there are a few more issue regarding branching and merging.

If my argument is not good enough to make you not use submodules and you go ahead, instead of updating NODE_PATH you can just add a proxy file to your node_modules to avoid relative paths:

In node_modules/models.js:

module.exports = require('../lib/models');

This might not be the best thing to do but you'll avoid relative paths for that module all across the application.

If you have node_modules under .gitignore you'll have to omit this one file:

node_modules/*
!node_modules/models.js

And you might want to add it to bundledDendencies in package.json. Yeah, it's a bit messy but you'll avoid relative paths and be able to move folders around with messing things up (too much).

Long story short: Adding your business dependencies to package.json might be what you are looking for.

Community
  • 1
  • 1
Maroshii
  • 3,937
  • 4
  • 23
  • 29
  • 1
    I was browsing some of my old questions and realized I never marked your answer as accepted even though I wound up making those assets individual packages per your recommendation. So thanks! – Aapo Kiiso Jun 24 '14 at 08:34
0

So basically this means it's considered a bad practice and slows down the app

Yes, it is considered a bad practice. It is useful sometimes, but you'd better have a good reason for it.

No, it will not slow down the app.

alex
  • 11,935
  • 3
  • 30
  • 42