Accommodate large projects with multiple package.json files

[mistermoe]

Let's say we have a directory structure like the following:

.
├── clients
│   └── mongo.js
├── components
│   ├── api
│   │   ├── package-lock.json
│   │   ├── package.json
│   │   ├── src
│   │   │   ├── core
│   │   │   │   └── start-crawl.js
│   │   │   └── index.js
│   │   └── test
│   │       ├── b-tests.js
│   │       ├── c-tests.js
│   │       └── pre.js
│   ├── cqm
│   │   ├── package.json
│   │   └── src
│   └── preprocessor
│       ├── package.json
│       └── src
├── package-lock.json
└── package.json

The top level package.json contains all of the node modules used across all components. Then, for each component, you have a package.json with that component's specific dependencies.

It would be nice if you could add module-alias as a common dependency and then define the aliases specific to each component within that component's package.json and also have the aliases used amongst all components within the root package.json. A buddy of mine and i have a working fork of this that required minimal changes. It starts at the top level like you do and simply traverses down into each directory. Is this something that you'd be willing to consider merging in if we submit the pull request? Additionally, beyond being able to support node 0.10, 5.0 and stable, are there any limitations or constraints we should be aware of?

[ilearnio]

I just checked the fork you mentioned. From what I see there could be problems with conflicting alias names. E.g. if you will have ~ alias in root directory and same ~ in children directory then they will conflict.

I wouldn't want such deep traversing to be a part of this package, because it comes with a cost of performance. And also because it is possible to handle this case without touching "module-alias" core, by using custom handler function. You can check this comment I posted to the similar issue https://github.com/ilearnio/module-alias/issues/28#issuecomment-407346402

[mistermoe]

1. Fair point. We could simply throw an error if we run into a conflicting alias if you'd like. Though i'd like to mention that this problem exists even without our addition in the sense that someone could add two aliases named ~ pointing at two separate paths and one would silently override the other without any sort of error or warning

2. I can see how you'd be concerned about performance here though i think we should be cognizant of the fact that it only happens once right when an application is starting. I can post a benchmark of how much time is added on average by creating a project containing 10-200 nested directories so we can get an actual idea. On the other hand, if there are rare use-cases which are constantly resolving aliases over and over again we could simply provide an options object that is passed in when module-alias is required that allows you to opt into accommodating large projects or even something like require('module-alias/register-multi-project')

Thoughts?

[ilearnio]

I am thinking that it would be best if module-alias could be used in multiple places, including separate packages in node_modules and nested/child packages like you have, and it will add aliases to some global stack that will be shared between module-alias initializations. That will solve a lot of existing problems. Maybe I'll add a ticket for that