Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Load config from NPM package #183

Open
dalgard opened this issue May 6, 2019 · 1 comment
Open

Load config from NPM package #183

dalgard opened this issue May 6, 2019 · 1 comment

Comments

@dalgard
Copy link

dalgard commented May 6, 2019

Sharing a preset across teams or packages is a great way to reduce complexity. It surprises me that PostCSS forces me to use a postcss.config.js file rather than giving me the option to point to a shared package.

Passing a package name instead of a simple path is easy to integrate with existing options. An intuitive command line syntax might look like this:

postcss --config myPackage
postcss --config myPackage/path/to/config.js
postcss --config @myOrg/myPackage/...

Although, the preferred option would clearly be referencing it in package.json:

  "postcss": "myPackage"
  "postcss": "@myOrg/myPackage/path/to/config.js"

  "postcss": {
    "config": "@myOrg/myPackage/path/to/config.js"
  }

Prettier implements sharing configs quite beautifully with its package.json option.

To minimize friction for the user, the path string should optimally be resolved in the same way module paths are resolved in Parcel or Webpack.

@majo44
Copy link

majo44 commented Apr 29, 2021

Hello, I also looking for such option.
For the monorepo, or multiple packages will be very useful to have possibility for share the config, just by referencing the package which that config delivers just by the literal.
As alternative approach to config option we can consider extends config property like the:

ect.

Looks like the extends approach is become some typical for the problem.
extends approach is also a bit more flexible as it also supports the real configuration extending.
On other hands will require some rethink how to resolve plugins.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants