Support for config modules

Hello there, love your work here.

I’ve been wanting to try and move some of my default config settings into a module. Given that a chunk of my fav tools are already using cosmiconfig, I wondered if adding support into this module would be a great way to take a stab at this.

For example, I normally add

  "prettier": {
    "printWidth": 120,
    "semi": false,
    "singleQuote": false,
    "trailingComma": "es5",
    "bracketSpacing": true
  },

To every repo’s package.json.

In an ideal world I could create a module called cosmiconfig-orta which would contain either:

• a package.json with the prettier key
• a prettierrc

Then prettier would use those settings instead of me needing to add them to each repo. Meaning I can keep both the locked dependencies and their config in a single module.

---

Side note: I’m happy to implement this.

[davidtheclark]

@orta I really like the idea. I would love to have something like this myself — a single npm package that would include the eslint, prettier, husky, lint-staged, stylelint, remark-lint, etc. configs that I reproduce repeatedly.

However, I don’t think that’s within the scope of cosmiconfig. Cosmiconfig is a low-level tool and each of the dependent projects, like Prettier, actually determine their own configuration API. Prettier needs to decide upon and document how the user configures it — then Prettier can use cosmiconfig behind the scenes to enable that pattern. The dependent gets to decide which of cosmiconfig’s features it uses; and if the dependent package decides to drop cosmiconfig to load its config in some other way, the end user shouldn’t be disturbed by that move.

It seems to me that this proposal would slide behind the public APIs documented by dependents like Prettier. We can’t make that decision for dependents, though; we can’t provide a feature that would encourage end users to load config for some dependent in a way that is not what that dependent deliberately chose.

So I think this idea should be brought up a level, to the packages that end users install, like Prettier, stylelint, etc. If they want to band together and provide a new way of loading configuration that enables these configuration-bundle packages, that’s up to them. (And I think they could probably accomplish this already by pointing cosmiconfig in the right direction.)

[orta]

I can’t tell if you’re trolling, but you can determine it by either looking for the keys in the package.json or if it’s in node_modules. I try keep as many settings as possible in package.json. I’m not quite sure how that really is relevant though?