Default configuration

[stefanpl]

I would expect this package to work without having to provide a config file. Sensible defaults should be applied when there is no such file – instead, the program will just fail right now.

This would enable one-off usage outside a given project, like:

npx svglint my-not-so-proper.svg

I'm a big fan of linters, and really like the idea of constraining and checking svgs. Hope to see this project grow 🌱

[ericcornelissen]

Thanks for your input @stefanpl, to what extend would not requiring a configuration file, as per #10, be a suitable solution for you?

Beyond that, do you have any suggestions for sensible defaults for SVGLint?

[stefanpl]

Hi @ericcornelissen ,
thanks for getting back to this. #10 sounds pretty much like what I had in mind – sorry for not having seen this before opening an issue. I'll close this one 👍

Regarding sensible defaults – I'm really not an SVG expert, that's why I was looking for a linter to help me notice my problems.

I use SVGs exclusively for the web, where (I imagine) the defaults are different from other environments. Maybe you could have different sets of defaults (or just one, for starters), that can be specified via a flag. That way, you could even keep the current behaviour for throwing if no config is provided.

Running without a config file, with the web defaults:

npx svglint --web my-not-so-proper.svg

Or the video defaults (whatever that may be … )

npx svglint --video my-not-so-proper.svg

Or assuming a config file:

npx svglint my-not-so-proper.svg

I'd suggest that if you don't provide a defaults flag, and there is no config, an error is thrown. The error message should indicate which defaults you can use. If you provide a defaults flag, and there is a config file, the defaults should take precedence, but this should emit a warning.

Just my 2 cents … since I'm pretty caught up in other projects right now, I won't be able to support with implementing this. But maybe you can get something out of it :)

[ericcornelissen]

Thank you very much for the thoughtful comment @stefanpl! (and no problem for not having found the other issue)

I think we will start by removing the need for a configuration file (which will basically just validate your SVG) and we can add some sensible defaults to that later (e.g. there must be an attribute like xmlns="http://www.w3.org/2000/svg" on the <svg>), of course it will be important to communicate that the results of using SVGLint CLI without configuration may break even if a non-major release is released.

As for your suggestion of different defaults. I think web is the primary use case by a large margin, so I think we can use defaults for the web as the default defaults. We can always add support for other default rulesets in a non-breaking way using the CLI flag style you suggested.

And lastly, just a note to my future self - or anyone looking to implement sensible defaults - it may be interesting to support "extending" the default rules.

I'll open this issue again as I'm interested in supporting the sensible defaults part, which is not explicit in #10.