Is it possible to break down the dependency list of a (published) package by creating new (non-published) "sub"-packages?

Question

I maintain a JavaScript library that is published on the npm registry and it has lots of dependencies. It gets difficult to keep track of what part of the code depends on what external packages.

Unfortunately neither lerna, yarn's workspaces, npm link, or npm's local path dependency declaration help. (I explain why after the example.)

I want to be able to break down the dependencies list declared in package.json by extracting some of the dependencies into new "sub-packages".

So, instead of having the following dependency list

// ~/code/example-lib/package.json
{
  "name": "example-lib",
  "dependencies": {
    "lodash": "*",
    "request": "*",
    "chalk": "*",
    "bluebird": "*",
    "mz": "*",
    "moment": "*",
    "socket.io": "*",
    "socket.io-client": "*",
    "react": "*",
    "react-dom": "*"
  }
}

I want to extract some of the dependencies into a new local package example-lib-subpackage. With local I mean that example-lib-subpackage is only meant to be consumed by example-lib.

example-lib-subpackage's dependency list would be;

// ~/code/example-lib/packages/example-lib-subpackage/package.json
{
  "name": "example-lib-subpackage",
  "dependencies": {
    "lodash": "*",
    "request": "*",
    "bluebird": "*",
    "moment": "*",
    "socket.io-client": "*",
    "react": "*",
    "react-dom": "*"
  }
}

and example-lib's dependency list would then be considerably reduced to;

// ~/code/example-lib/package.json
{
  "name": "example-lib",
  "dependencies": {
    "chalk": "*",
    "example-lib-subpackage": "./packages/example-lib-subpackage",
    "mz": "*",
    "socket.io": "*"
  }
}

Note how example-lib now depends on the local package example-lib-subpackage;

  ...
  "name": "example-lib",
  "dependencies": {
  ...
    "example-lib-subpackage": "./packages/example-lib-subpackage",
  ...

Has anyone achieved this? It would be super convenient.

Note that lerna and yarn's workspaces feature only help if you are ok with publishing the local packages to the npm registry. But in my case publishing the local package example-lib-subpackage to the npm registry doesn't make sense.

Also, npm link and npm's local path dependency feature only work for packages that aren't published but example-lib needs to be on the npm registry.

Local paths [...] should not be used when publishing packages to the public registry.

Quote from https://docs.npmjs.com/files/package.json#local-paths

Answer 1

Since package.json is just a JS object, you might extend it before publishing to NPM.

On prepublish:

• update package version
• remove package.json local example-lib-subpackage dependency
• extend example-lib dependencies with the one declared in example-lib-subpackage
• optionally run a few tests over your updated package.json
• publish
• revert original dependency object
• commit new version

PouchDb follows a vaguely similar approach described more in detail here and here.

Answer 2

I was thinking you could use a build tool to maintain multiple package.jsons and have them compile down to the real one - but you'd be fighting the platform the whole way. You'd have to have your own CLI for installing, and it would be a mess.

You say:

Note that lerna and yarn's workspaces feature only help if you are ok with publishing the local packages to the npm registry. But in my case publishing the local package example-lib-subpackage to the npm registry doesn't make sense.

I don't think you are going to find a solution that makes perfect sense (if you're going down the route of trying to do completely nonstandard things with npm), and I am curious why you are ruling out breaking out example-lib-subpackage into its own repo - that seems like the obvious solution.