.config/package.json

[shannonmoeller]

As more and more tools have become best-practice when authoring npm modules, from package.json to .*rc to *file.js, the root directory of projects has become a very loud place. This dot-noise pushes README content farther and farther down the main page of git repos.

What if the above could optionally be simplified to the following?

This is a simple example and that's already about a 30% vertical space savings. I'm starting the conversation here, but I'll be submitting similar issues to the findup, findup-sync, karma, travis-ci and zuul repos.

[othiym23]

package.json is the sole point of contact between npm and the Node module loader (which needs it to resolve the location of the main entry in the package). Its contents and its location are inherited from CommonJS, and a whole constellation of tools require it to be at the root of the package folder. This is one of the few immutable constants of npm, and is probably never going to change.

[SgtPooki]

@othiym23 not sure if you actually looked at the changes.. but package.json is still in the root. I think Shannon was mostly trying to get some sort of standard started for the front-end where we stop allowing every new plugin from creating dotfiles in the root and cluttering our project root.

Sure, projects should be allowed to have their own config file, but having a convention for these config files, or common home, would go a long way.

[othiym23]

@SgtPooki I saw the picture, but I also saw the title of this issue, which is what I was responding to.

I understand that it can look cluttery and feel awkward when the root directory contains lots of configuration files for lots of different tools (and that's a real ergonomic concern when you're working on a project day-in and day-out), but I also know, from maintaining one of those tools, that changing where configuration is stored after a location has been established is almost always far trickier than it looks. People upgrade their tools more slowly than we might like, so you either have to compel users to upgrade (somehow: we still regularly get support issues on this issue tracker from people running npm@1.0.x from users running old LTS distributions of various flavors of Linux) or keep files in their old locations for an indefinite time until you've sort of guessed that enough users have upgraded to the new versions that it won't break things for too many of them when you upgrade to new locations.

To be perhaps overly reductive, it's a tradeoff between aesthetics and supportability, and I come down on the side of supportability. It's selfish, but at the same time supportability is itself a proxy for the quality of a user's experience.

[shannonmoeller]

@othiym23 I admit that it's likely too late for npm. At least without a major point release and some clear documentation of the feature. (Maybe when ES6 modules land?) Perhaps in addition to this feature, one of the core Node.js modules could be updated to include a package.json getter rather than relying on require()ing a specific path.

Basically, I'm recommending that the .config/ directory be added to the list of default locations to check for configuration files. The idea here is to foster the use of XDG Base Directory Specification where $HOME is a module's root directory to declutter module repos.

So the search would look like this where X is the current directory:

1. If X/file.ext exists, load it. STOP
2. If X/.config/file.ext exists, load it. STOP
3. Change X to parent directory. GO TO 1

Some modules allow the path to be configured in package.json, but that's replacing file noise with config noise and requires additional effort in every project.

[qfox]

I'm definitely for using XDG. Would be great to start supporting this asap to get it done for 1-2 years (when all users will update their npm's). Even if the process will took 5 or 10 years...

It can be done as experimental thing with warning and with use env flag to disabling warning for old version. ;-\

[othiym23]

Perhaps in addition to this feature, one of the core Node.js modules could be updated to include a package.json getter rather than relying on require()ing a specific path.

That would require making changes to one of the most locked-down APIs in Node, and I can say with some confidence that it is never going to hapen. The location of package.json is integral to the stability of the entire npm ecosystem. It will not change.

[callumacrae]

@shannonmoeller I think a better solution would be for GitHub to have an option to hide dotfiles. Until then, this plugin for Chrome and Opera exists: https://github.com/sindresorhus/github-hide-files

[nivthefox]

Even if it doesn't hide dotfiles, Github should at least push them further down the list. Presently they are 'alphabetically' before a, because their position in ascii and utf-8 says they are. But there's no logical reason to sort . before a, so shove them to the back and problem solved (or at least reduced).

That said, this is getting off topic since it's now a suggestion for github rather than npm. I agree with @othiym23 that a change in NPM is not a good idea, in this case.

[shannonmoeller]

@othiym23 Recommend locking this issue.

[othiym23]

I agree, @shannonmoeller. Locking.

BTW, I agree with the spirit of what you're trying to do, which is to try and make it easier to see the structure of a project from the outset, but a lot of these decisions need to be baked in (and driven to consensus) before there are big scary ecosystems built around them. That said, this would have been a tough sell even from the beginning, because either you would have had to catch CommonJS before it coalesced into a spec / de facto standard, or convinced @ry and @isaacs that it was a good idea to abandon CommonJS early on.