Lets make a better package.json

package.json.md

A better package.json

Right now everybody seems to be creating their own .json.

Here are the reasons I think it happens:

1. node dependencies may be different than browser dependencies
2. node main.js may be different than browser main.js
3. {project} {something} may be different than {project2} {something2}
4. {not-npm} feels like it has to be a parasite in an npm-centric package.json

I think #4 is the big one.

If there are other reasons, please let me know.

I'd like to stop doing this, and I think everybody else would too.

Here's how it could work:

Everybody, including npm, can use a namespace in package.json to override the primary values.

As I understand it, this is how volo, browserify and jam already do things, so lets consider two other popular javascript package managers. (Yes, I know browserify is not a package manager, but it is related to this problem.)

A package.json with bower being the primary target might look like:

{
  "name": "tophat",
  "version": "1.0.2",
  "description": "you know you look best in a tophat",
  "main": "tophat.js",
  "dependencies": {
    "es5-shim": "1.0.0"
  },
  "npm": {
    "version": "0.2.1",
    "dependencies": {}
  }
}

Bower would install es5-shim but npm would not because it doesn't need it. Additionally, npm gets a pre-release version number because maybe node support is still in development.

Finally, insofar as bower, jam, and volo share the same config, you only need to override for npm.

A package that targets npm first could look something like:

{
  "name": "corsette",
  "description": "you know you look best in a corsette",
  "main": "index.js",
  "bower": {
    "main": "corsette-browser.js"
  }
}

This approach of embedded, overridable package manager configs allows

1. any package manager to "own" the package.json
2. any other package manager to override the "owner" config
3. authors to stop repeating themselves

Having 5 different .json files in a project may seem like no big deal, but it is causing friction with some, which means managing JavaScript dependencies is harder than it should be. I think this is a solvable problem. Lets make things simpler.

this assumes npm is on-board with using .npm I guess right? Personally I'd rather spend time just building things than wasting time arguing about files, ultimately they will all be replaced by something else in the future, especially once web components and ES6 module stuff becomes widely adopted, then we'll have some real problems. In general I'd +1 but npm will be stuck with root-level stuff for a long long time, I kind of prefer that I can look at a repo and see what it supports via the filenames, maybe what we really need is common.json and "include": "common.json", but that's lame..

Personally I'd rather spend time just building things than wasting time arguing about files, ultimately they will all be replaced by something else in the future

My motivation in this is to try to stop arguing with people about supporting x.json so people can more easily build stuff :) Some of us have to have these annoying conversations to benefit everybody else, and to figure out what that future thing is.

especially once web components and ES6 module stuff becomes widely adopted, then we'll have some real problems

This is exactly what my eye is on, templates, css, telling the package manager you're authored in es6, etc.

but npm will be stuck with root-level stuff for a long long time

Would love to hear @isaacs thoughts on all of this :)

Also, thanks for your thoughts TJ :)

np, I think from a future-proofing perspective non-package.json may be the way to go, node will be coupled for quite a long time since the ecosystem is so large, so every package.json out there is pretty much frozen. This is pretty common in general with software though, you get stuck with legacy systems and every so often it's "healthy" to break completely free and start fresh. Hell even if we do that it will happen again in another 2 or 3 years for sure haha :D

"namespacing" everything else but npm seems the way to go. Trying to change everyones package.json format is not going to work if we are targeting a relative short time for it to be usable.

Trying to change everyones package.json format

@guilhermeaiolfi "everyone" is package authors or package managers?

If authors, npm-targeted package.json will continue to work just fine w/o modification.

If package managers, that's the point of this thread, to see what the interest is. If it turns out that npm says, no, "we'd like to continue to keep a monopoly on package.json" then I guess that's that. But I think npm should be mindful of the larger ecosystem, and I have a feeling the powers-that-be are getting more sympathetic to this.

The problem with your package.json with the npm namespace is that it's not clear at all that the file is targeting the bower registry. If I come to your repo and I see that package.json, I don't understand what package manager you're using. And worse yet, most people will think you're just using npm.