Is it a good idea to require regular js-files without absolute path?

[Alexander Myshov]

work with the code which isn't include an absolute path in a require statement. For example i have this structure:

project
|
+-helpers
|   |
|   +-helper1.js
|   +-helper2.js
|   +- ...
|
+-modules
    |
    +-moduleDirectory1
    |    |
    |    +-module11.js
    |    +-module12.js
    |
    +-moduleDirectory2
         |
         +-module21.js
         +-module22.js

And modules which use helpers just include them this way:

// for example module11.js
var helper1 = require('helpers/helper1');
var helper2 = require('helpers/helper2');
helper1.someFunction();

Application work just fine, but the development tools like ternjs, and node plugin for vim don't recognize this statement properly. When I replace it with something like this: require('../../helpers/helper2') plugins start work.

I've searched a while but didn't find any information about "requiring" regular files without absolute path. Only about node_modules in official docs:

>> Without a leading '/' or './' to indicate a file, the module is either a "core module" or is loaded from a node_modules folder.

Is it a good idea to use including a regular files without an absolute paths?

[Zach Rollyson]

I've always used './' without any problems, which is relative.  The dot slash just references the current directory.  I would think that this way (the dot slash) would be the proper way to include files.

[Aria Stewart]

>> Without a leading '/' or './' to indicate a file, the module is either a "core module" or is loaded from a node_modules folder.

Is it a good idea to use including a regular files without an absolute paths?

You in fact cannot include your own package's files without ./ -- if you omit that, you're stuck with absolute paths (never a good idea in a portable module without good reason), or loading from other modules -- require('helper/index.js') loads index.js from the helper module in node_modules; require('./helper/index.js') loads index.js from the helper directory next to the file the statement is in. Very different behaviors and meanings.

[Alexander Praetorius]

// [SOURCE/index.js] - What about:

var // DEPENDENCIES
    installedDependency1 = require('installedModule1'),
    installedDependency2 = require('installedModule2'),
    installedDependency3 = require('installedModule3'),
    // INTERNALS
    _config              = require('_config'),  // module.exports = { /* stuff with relative paths, e.g.*/ pkg: require('../../package.json') }
    _server              = require('_server'),
    _shared              = require('_shared'),
    _client              = require('_client');
      


/*.

├── node_modules

│   ├── installedModule1

│   │   ├── node_modules

│   │   │   ├── installedSubModule1

│   │   │   │   ├── index.js

│   │   │   │   ├── package.json

│   │   │   │   └── README.md

│   │   │   ├── installedSubModule2

│   │   │   │   ├── index.js

│   │   │   │   ├── package.json

│   │   │   │   └── README.md

│   │   │   └── installedSubModule3

│   │   │       ├── index.js

│   │   │       ├── package.json

│   │   │       └── README.md

│   │   ├── index.js

│   │   ├── package.json

│   │   └── README.md

│   └── installedModule2

│       ├── index.js

│       ├── package.json

│       └── README.md

│

│

├── package.json

├── readme.MD

└── SOURCE

    ├── index.js

    └── node_modules

        ├── _client

        │   └── index.js

        ├── _config.js

        ├── _server

        │   └── index.js

        └── _shared

            └── index.js

*/

--
Job board: http://jobs.nodejs.org/
New group rules: https://gist.github.com/othiym23/9886289#file-moderation-policy-md
Old group rules: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
---
You received this message because you are subscribed to the Google Groups "nodejs" group.
To unsubscribe from this group and stop receiving emails from it, send an email to nodejs+un...@googlegroups.com.
To post to this group, send email to nod...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/nodejs/a9d3b26c-9724-49a2-bc5e-b1011ba3ef3a%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Aria Stewart]

On Tuesday, April 14, 2015 at 10:05:24 AM UTC-4, serapath wrote:

├── package.json

├── readme.MD

└── SOURCE

    ├── index.js

    └── node_modules

        ├── _client

        │   └── index.js

        ├── _config.js

        ├── _server

        │   └── index.js

        └── _shared

            └── index.js

Oh my, that is definitely weird!

I think once you get to _naming things you've gone off the rails somewhere.

What's the actual problem you're trying to solve?

Aria

[Alexander Praetorius]

I want to avoid "relative require" (e.g. require('../../foobar');)
I get that by stuffing everything into a "node_modules" folder.

I want my project's internal modules, which are not published (at least yet) and only something custom to my project, to be available in the same way the installed modules are.

So I have a "node_modules" folder at the project root, where all the "npm install"ed stuff goes in.
I have another in "SOURCE/node_modules" which I maintain manually.
If I ever feel like, I rename that internal module from "_foobar" to "foobar" and publish it and "npm install" it.

The advantage of the "_naming" is, that I can immediately see which modules are "npm installed" and which are actually local modules, so I maintain them myself and I know where to look for.

Everything that I have to manually, for example:

[SOURCE/node_modules/_config.js]
module.exports = { pkg: require('../../package.json') };

I require in "_config.js" by convention, so I can access it in the rest of my app, by "require('_config').pkg" without further need for relative require statements.

--

Job board: http://jobs.nodejs.org/
New group rules: https://gist.github.com/othiym23/9886289#file-moderation-policy-md
Old group rules: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
---
You received this message because you are subscribed to the Google Groups "nodejs" group.
To unsubscribe from this group and stop receiving emails from it, send an email to nodejs+un...@googlegroups.com.
To post to this group, send email to nod...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/nodejs/23f45c37-314d-4381-8a66-08318661966e%40googlegroups.com.

[// ravi]

On Apr 14, 2015, at 9:21 PM, Alexander Praetorius <d...@serapath.de> wrote:
>
> I want to avoid "relative require" (e.g. require('../../foobar');)
> I get that by stuffing everything into a "node_modules" folder.
>

With the confession that I have not been following this thread and have not taken the trouble to understand the full discussion, I want to add one comment. I too have tried to avoid relative paths in my code. At the same time, I do not want to stuff all my libraries and modules into “node_modules” in the app root directory. My solution is/was to use NODE_PATH in a manner similar to how library paths have been used traditionally for years on Unix. Works perfectly for me:

* External modules are in /X/Y/node/lib/……… (installed using ‘npm install -g’)
* My system wide modules are in /A/B/lib/………
* App level modules are in /A/B/app1/lib/……
* App config is in /A/B/app1/config/……

NODE_PATH is set by a wrapper to: "/A/B/lib:/A/B/app1/lib:/A/B/app1/config:/X/Y/node/lib”. Would have made my life easier if require.path had not been removed, but such is life.

—ravi

[zladuric]

You can achieve similar via either a private npm registry or private git packages. And several other ways, probably.

If your helpers really are good candidates to be standalone, create a separate git repo and add that to package.json as

"dependencies": {

"express": "*",
"helper1": "git.repo.url#branch"
}

Then when you require helper1, it is absolute.
HTH

[Alexander Praetorius]

I dont know if they are good candidates.
Thats why i put them into "SOURCE/node_modules/..." and maintain them manually.
Once I figure I use them often or need them in other projects as they mature, then I publish them on github or npm (changing their name from "_foobar" to "foobar") and I make a simple project wide "search and replace" of (s/require('_foobar')/require('foobar')) if the latter was a free name on npm.

It's not so much about "private registry or git repos", it's more about hacking together some modules to solve my immediate problems and then move on. Once they mature and I see they are re-usable, of course, I continue and publish them and make them available to others or at least my other projects... :-)

--
Job board: http://jobs.nodejs.org/
New group rules: https://gist.github.com/othiym23/9886289#file-moderation-policy-md
Old group rules: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
---
You received this message because you are subscribed to the Google Groups "nodejs" group.
To unsubscribe from this group and stop receiving emails from it, send an email to nodejs+un...@googlegroups.com.
To post to this group, send email to nod...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/nodejs/998c2d12-5e1a-4978-8d21-f6cff880b720%40googlegroups.com.