Support for ".stylussupremacyrc" and/or ".stylussupremacyrc.js"?

[maranomynet]

It would be great if the config could be stored in a single file that would both be picked up by all editor plugins and the CLI command.

...similar to the way you pick up .stylintrc.

Please allow the option of using a JavaScript module, as it allows for several interesting use-cases.

[ThisIsManta]

Hello,

Do you mean making Stylus Supremacy (NPM module & VSCode extension) automatically pick up .stylussupremacyrc? Are you aware that using NPM module, you can do so by specifying --options parameter?

[maranomynet]

I am aware of the --options parameter, but I'm thinking of ways to make these settings easily portable between npm scripts, VSCode, Atom, etc. with a single *rc file as the source of truth.

...exactly like you do with the .stylintrc files.

On second thought, maybe I shouldn't be using stylusSupremacy.* settings at all, and just use .stylintrc.

[simonhaenisch]

I'd rather want this to be configurable from within package.json, cause that's how I configure many other tools, e. g. prettier, linters, and so on, without cluttering my project with heaps of rc files.

E. g. in package.json:

{
  "name": "my-project",
  "version": "1.0.0",
  "...": "the other stuff",
  "prettier": {},
  "stylusSupremacy": {
    "insertSemicolons": false,
    "insertBraces": false
  }
}

[ThisIsManta]

My thought against having a default config file is, without going through the document, you will never know which configs will be used. Personally, explicitly running stylus-supremacy format --option config.json is my best practice because you can obviously see which config is being used without searching for .xxx-rc file or the very bottom of package.json.

[ThisIsManta]

Hello @maranomynet,

Yes, using the VSCode extension, you can use .stylintrc as the default config file for Stylus Supremacy. The below paragraph could be useful for you.

[maranomynet]

Yes I had noticed that, and I will be using .stylintrc ... when #43, #44, #46 and #49 have been fixed. :-)

Until then I don't feel quite safe auto-formatting our existing codebase.

[maranomynet]

...the config files don't have to be implicitly selected. If you provide a stylusSupremacy.configFile setting in VSCode/Atom/etc. then a single config can be shared between editors and npm scripts.

Allowing the config to be exported from a JavaScript module (like ESLint, Rollup and others do) makes it possible to compose the config based on other project settings and/or some centralized style-configs, etc.

[simonhaenisch]

because you can obviously see which config is being used without searching for .xxx-rc file or the very bottom of package.json.

Nope, in the CLI arg I can only see where my config file is but not what it includes, so in either case I have to look it up, stylus-supremacy.json, package.json, .stylintrc... doesn't matter where, the point is I want to be able to configure this the way that best fits my project, not according to your personal best practices... maybe this is just not the right tool for me then 🙃

[ThisIsManta]

in the CLI arg I can only see where my config file is but not what it includes

That's true but my point is, it's straightforward to keep the config file path in CLI arguments.

This is an open-source project. You are welcome to edit whatever float your boat and create a pull-request.