Lobby for `.config/`

[shannonmoeller]

Responses from maintainers to requests for optional .config/ support varied widely. Some plan to implement, others won't implement but were supportive of the idea, others slammed the door entirely. Among the more supportive responses was the recommendation for publishing a module that implements the requested logic followed by pull requests.

This module is the brain child of those conversations and will be used as a base for submitting PRs. Eventually it will be updated to either use or establish a pattern for using findup-sync to locate configs. This issue will track the progress of PR implementations and their acceptance or rejection.

• [x] ~~npm~~ (rejected)
• [x] ~~jspm~~ (accepted)

---

• [ ] bower
  • [x] Feature requested. (open)
  • [ ] Fork
  • [ ] PR
• [ ] eslint
  • [x] Feature requested. (rejected, unsupportive)
  • [ ] Fork
  • [ ] PR
• [ ] findup
  • [x] Feature requested. (open)
  • [ ] Fork
  • [ ] PR
• [ ] findup-sync
  • [x] Feature requested. (rejected, supportive)
  • [ ] Fork
  • [ ] PR
• [ ] grunt
  • [x] Feature requested. (open)
  • [ ] Fork
  • [ ] PR
• [ ] gulp
  • [x] Feature requested. (rejected, mildly supportive)
  • [ ] Fork
  • [ ] PR
• [ ] karma
  • [x] Feature requested. (open, supportive)
  • [ ] Fork
  • [ ] PR
• [ ] liftoff
  • [x] Feature requested. (open)
  • [ ] Fork
  • [ ] PR
• [ ] jscs
  • [x] Feature requested. (open)
  • [ ] Fork
  • [ ] PR
• [ ] jshint
  • [x] Feature requested. (open, mild support)
  • [ ] Fork
  • [ ] PR
• [ ] travis-ci
  • [x] Feature requested. (open)
  • [ ] Fork
  • [ ] PR
• [ ] yo
  • [x] Feature requested. (rejected, supportive)
  • [ ] Fork
  • [ ] PR
• [ ] zuul
  • [x] Feature requested. (rejected, mildly supportive)
  • [ ] Fork
  • [ ] PR

[shannonmoeller]

Another attempt at championing this idea: https://github.com/nodejs/tooling/issues/79

[ssbarnea]

How about teaming-up with this challenge? Getting the first test of tools to to adopt it would be the hardest and we need to start with less mainstream ones. Check https://dot-config.github.io/ -- the first 10 would be the hardest.

I a little bit disappointed of general view on this from other which do seem to want to use the root level to advertise the tool use, at detriment of developer experience. Moving stuff to .config is seen as reducing the visibility. Probably none will confess that but it is there.

I would even say that it would be a bad idea to aim too high before we have few smaller projects adopting it. A bottom-up approach seems better in that case.