Skip to content

File inclusion support within package.json #3966

rothshahar opened this Issue Oct 3, 2013 · 5 comments

3 participants


Here's a feature request :-)

Support for inclusion of files within package.json will allow for easier management and automation.

For example, developers manage the dependencies/devDependencies keys. CI build updates the version key automatically. The scripts key is managed by a central team.

It'll be useful to be able to break package.json into 3 files e.g., package.version.json and package.common.json and allow package.json to specify a directive that simple includes the three files so the end result is as if all the 3 files appeared together in package.json.

The benefits are that package.common.json can be updated without worrying about maintaining the changes that were manually added to the other two files as well as the fact that there won't be any git merge conflicts as a result of two different commits updating the same file.

Maybe the format can be as simple as:

    includes: ["package.common.json", "", "package.version.json"]

Files that appear later in the array will override values that appear in earlier files.

rlidwka commented Oct 6, 2013

npm is changing package.json sometimes (npm install --save, npm version, etc.), and it's just rewriting the whole package.json with the new parsed version each time. So I smell a lot of potential bugs around.

What would happen if an included file is out of the tree (i.e. "../../")? Should npm pack it all into one file on publish?

npm member
domenic commented Oct 7, 2013

Yeah, this is not really in scope of npm. You should write a preprocessor though and publish it to npm, then you can use it to create real package.jsons that npm can accept.

@domenic domenic closed this Oct 7, 2013

The problem with a preprocessor is that the package.json file can become stale and there's no mechanism to bring it up-to-date by running the preprocessor before the npm commands that peek into it are executed.

npm member
domenic commented Oct 8, 2013

I mean, I sympathize that it's not always as easy to write a new tool as it is to add features to someone else's tool, but that complexity burden has to go somewhere, and putting it on us (and all users of npm) is not fair. These are solvable problems; you can have a watch utility that runs your preprocessor whenever the source files change, for example, or a pre-commit hook to run the preprocessor before committing any changes.


I had no intention to add complexity where complexity is not needed. I thought it might be a good feature to add but if people don't find it useful then I'll just solve it for myself for my use cases.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.