Ecosyste.ms: Awesome

An open API service indexing awesome lists of open source software.

Awesome Lists | Featured Topics | Projects

https://github.com/billiegoose/my_modules

Keeps local modules out of node_modules, but still have working 'npm install' and 'require()'.
https://github.com/billiegoose/my_modules

Last synced: 24 days ago
JSON representation

Keeps local modules out of node_modules, but still have working 'npm install' and 'require()'.

Host: GitHub
URL: https://github.com/billiegoose/my_modules
Owner: billiegoose
License: isc
Created: 2016-03-05T00:10:56.000Z (almost 9 years ago)
Default Branch: master
Last Pushed: 2016-09-23T02:22:10.000Z (over 8 years ago)
Last Synced: 2024-10-06T03:21:43.689Z (3 months ago)
Language: JavaScript
Size: 8.79 KB
Stars: 2
Watchers: 2
Forks: 0
Open Issues: 0
Metadata Files:
- Readme: README.md
- License: LICENSE

Awesome Lists containing this project

README

## DEPRECATED

**I have ceased work on this project (and will hand over the project name if you ask nicely).**

# Recommended Alternative

In the original motivation for this module, I put forth this scenario:

> Say your project layout looks something like:
> ```
> cool_project
> `-- app.js
> `-- package.json
> `-- lib
> | `-- main.js
> | `-- logger
> | | `-- logger.js
> | | `-- package.json
> | `-- router
> | | `-- routes
> | | `-- router.js
> | | `-- package.json
> | `-- api
> | `-- index.js
> | `-- package.json
> `-- node_modules
> ```
>
> You like having your project in modules (`logger`, `router`, and `api`) because it aids in unit testing and separation of concerns, but don't like publishing every module separately as its own git repository or on npmjs.org. But you end up with a workflow like:
>
> ```
> $ npm install
> $ cd lib/logger
> $ npm install
> $ cd ../router
> $ npm install
> $ cd ../api
> $ npm install
> ```
>
> and you start to go crazy. Maybe you try moving them to the `node_modules` folder, possibly in their own @scope, and then fight with git and npm only to have it still act wonky. Maybe you try `npm link` and all the options for local require() paths from [this article](https://gist.github.com/branneman/8048520) but nothing is perfect so nothing sticks.

I have found a reasonable-ish solution to the craziness: *Put your package.json in the parent folder
of your app code.* Put your custom modules in `cool_project/app/node_modules` and
install your regular npm dependencies in `cool_project/node_modules` beside `app`.
When node's `require` does not find the module in the current node_modules folder,
it continues checking in each folder up to the root folder until it finds a module with the
right name. (This is probably a bad design decision, because it makes modules indirectly
depend on every folder above them as well as below them, but that is not a useful discussion to have
at this point. This is how `require()` works and we're stuck with it now.)

Restructured project layout:

Bear with me and I'll walk you through how this works.

#### Resolving npm modules from main code
Let us say cool_project/app/app.js contains `require('express')`. Resolving will go like this:

- Does cool_project/app/**node_modules** exist?
- Yes! Does cool_project/app/node_modules/**express** exist?
- No, go up one directory.
- Does cool_project/**node_modules** exist?
- Yes! Does cool_project/node_modules/**express** exist?
- Yes! Return module.

#### Resolving custom modules from main code
Suppose cool_project/app/app.js contains `require('logger')`.

- Does cool_project/app/**node_modules** exist?
- Yes! Does cool_project/app/node_modules/**logger** exist?
- Yes! Return module.

#### Resolving custom modules from custom modules
Let's say that router.js runs `require('logger')`.

- Does cool_project/app/node_modules/router/**node_modules** exist?
- No, go up one directory.
- Does cool_project/app/node_modules/**node_modules** exist?
- No, go up one directory.
- Does cool_project/app/**node_modules** exist?
- Yes! Does app/node_modules/**logger** exist?
- Yes! Return module.

#### Resolving npm modules from custom modules.
Say logger.js does a `require('chalk')`.

- Does cool_project/app/node_modules/logger/**node_modules** exist?
- No, go up one directory.
- Does cool_project/app/node_modules/**node_modules** exist?
- No, go up one directory.
- Does cool_project/app/**node_modules** exist?
- Yes! Does app/node_modules/**chalk** exist?
- No, go up one directory.
- Does cool_project/**node_modules** exist?
- Yes! Does cool_project/node_modules/**chalk** exist?
- Yes! Return module.

## Pros and Cons

Pros:

- No extra hacking needed besides the directory structure.
- Only one `npm install` command needed. No recursive installs.
- Is not disrupted by npm3 node_modules flattening.

Cons:

- Custom modules all live in one flat directory.
- All module dependencies are saved together, which can lead to version coupling between custom modules.
- Any "dependencies" listed in a custom module's package.json are a lie.
- That directory is named `node_modules` so you probably have to explicitly un-ignore it in source control.

The cons are not that bad IMHO. If your modules were TRULY uncoupled, you'd be publishing them as such. This strategy
is quick and works though, so you can gradually move code into modules for organization first, then work on
truly decoupling them (and giving them separate git repos and publishing them independently) later.

## Status

Unmaintained and deprecated. If you would like the "my_modules" package name I'm happy to hand it over.

## Changelog

2.0.1 - Deprecated

2.0.0 - Bumped major version because my_modules will now force npm to install packages locally inside each package (my_modules/*/node_modules) instead of letting npm3 do its flattened top-level install. This was necessary to allow running multiple "npm install"s in parallel without race conditions. Switching to parallel execution cut the install time for my project from 22m to 8m so it was definitely worth it.