Allow to specify a parent package.json

[mantoni]

The idea is to borrow Mavens parent.pom concept to allow specifying common dependencies, devDependencies, scripts, configs or any other property.

This would be extremely helpful when using npm as a build tool for dozens of modules following the same approach, e.g. within an organization.

Currently, I find myself repeating the same scripts and devDependency lists in a lot of modules. Every time I like to bump a dependency or tweek a script, this has to be applied in each module separately.

It would be nice to have a versioned parent package.json file that can be refered to using an expreasion like ^1.0.0.

I also use the same author and license values and most packages follow a naming convention to relate the npm module name with the git repository name. If those could be inherited from a parent definition as well, my package.json files would be a lot shorter.

Thoughts?

[smikes]

I think this is an interesting feature request. I can see how that would improve your ability to use npm for maintaining a lot of modules with common behavior.

One concern that I have is that when publishing the module, either the parent file would have to be included in the module tarball, or the parent data would have to be merged into the package.json of the module tarball, in order for the scripts (etc.) to be present.

Recently npm has been moving in the direction of making fewer changes in the package.json file than it used to, so this goes a little against the grain.

I'm sure some of the npm team will weigh in when they have a chance.

[mantoni]

@smikes I thought about potential package.json incompatibilities too. This could be solved by merging the parent.json and the package.json during npm publish. I consider this a module maintainers convenience feature. The resulting package.json does not need to retain the parent package information.

[othiym23]

This is a fraught suggestion, because it means that package manifests are no longer self-contained. I get the impulse towards DRY, but I feel like the explicitness of having everything included in a package trumps the savings of typing. Would making it easier to put shared dependencies into a template project created by npm init be enough? As it stands, I'm weakly -1 on this suggestion, because my experiences with this feature in Maven are one of the two main reasons I became disenchanted with it.

[mantoni]

I do see your point. The main thing that I'd actually want to share is npm run scripts. That is because we use npm as a build tool and have conventions in the team how they are layed out. If we decide to change the convention, it means that we have to change all the projects as we go, ending up in an inconsistent world. It's not really bad, but it would be super convenient to have this kind of "config" into a common place and apply semantic versioning to it.

+1. We are using npm with our private nexus and we have to copy and paste publishConfig in all projects. It's not so hard, but also not DRY

[kevinSuttle]

Would it be more valuable to specify a stub with default values populated for a custom npm init template? #10832

[kevinSuttle]

Seems @isaacs already did this: https://github.com/npm/init-package-json

[dsebastien]

I'm in favor of having an officially supported way to inherit properties/scripts/dependencies (or at least a part of those :p)

Having used Maven very extensively over the years, I see huge added value to being able to create a parent configuration, providing me with dependencies, dependency versions/version ranges, ...

At work, this helps us really a LOT to keep our projects on par with each other and it saves a lot of trouble (dependency hell and reinventing the wheel).

With npm, I actually feel like going back in time to a world where I need to re-define everything in each and every project, which is not a concern until you have to start updating/fixing things, at which point you always forget something and waste a lot of time along the way.

A good example of this issue is the number of yeoman generators that just provide you with a bunch of scripts and a set of gulp tasks. it's nice to get started, but when you have many projects, there's no way to keep generated projects up to date and in line with each other.

In my project (https://github.com/dsebastien/modernWebDevBuild), I've partly worked around this externalizing the gulp tasks and by providing client apps with a way to depend on my project without having to copy files around (i.e., they can upgrade a single dependency and get a fully updated build).

Maybe a first improvement could be to have the ability inherit scripts somehow (not necessarily through a parent package.json file).

For example it could already be nice to add a dependency to your project and have a way to import scripts from that dependency or allow that dependency to inject scripts that you can use on the command line as if they were part of your package.json

Of course there are always workarounds (e.g., provide a CLI as a dependency and have a single script pointing to the CLI in the client project), but I don't think it's the correct answer :)

[kevinSuttle]

If npm init and init-package-json had better docs, we might be closer to solving this, because as of right now, I couldn't tell you how to provide custom pre-filled values using either.

[sindresorhus]

👎 to the initial request. You're asking for something that goes against the core of npm. It's built on the idea of self-contained independent packages. Which is a great thing! Your problem could be solved by creating a master package and having other packages consume that one or use tooling to sync package.json contents. I don't think this is something npm should solve.

[sindresorhus]

Would it be more valuable to specify a stub with default values populated for a custom npm init template?

Could maybe be useful, but it's a slippery slope towards people demanding more and more features of init, which is just meant to be a simple way to get started. For more advanced usage, I would rather recommend using a scaffolder/generator, where there are lots of option both for ready made generators and creating a custom one:

• http://yeoman.io/generators/ (Finding generators)
• http://yeoman.io/authoring/ (Creating a generator)
• https://github.com/sindresorhus/generator-nm (Meant to be forkable)
• https://github.com/substack/pkginit