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

Using svgo as SVG linter #1425

Open
techquestions opened this issue Mar 14, 2021 · 11 comments
Open

Using svgo as SVG linter #1425

techquestions opened this issue Mar 14, 2021 · 11 comments

Comments

@techquestions
Copy link

Is your feature request related to a problem? Please describe.

I would like to use svgo as a "linter", that would validate against some rules specific to a project. An example of such rule is one that would validate the artboard size of the SVG (viewBox attribute value) but there are many more such rules that I have in mind.

I know that svgo is an optimizer, so I would like to ask if you are open to extend

Describe the solution you'd like

Looking at the current architecture of svgo, I think the solution would be to extend plugins to return diagnostic/validation information as well. This would work in a way similar to what ESLint does: by default it just reports failed rules but the user can also provide --fix flag to automatically fix the errors, if the given rule provides code transformations to perform autofix (the "fix" option would probably stay as the default in case of svgo).

Taking the "artboard size validation" rule, it could for example just check the viewBox , width and height attributes (based on the plugin configuration) and return some validation information, possibly with an autofix.

Also, it would be possible to use different output formats (again, based on other tools like ESLint: https://eslint.org/docs/user-guide/formatters/ or Stylelint), for example to format the output in JSON.

Describe alternatives you've considered
An alternative is to write a separate library. However, I think that the idea I am presenting fits pretty nicely into what svgo already does and into its architecture.

@techquestions techquestions changed the title Using svgo as linter Using svgo as SVG linter Mar 14, 2021
@TrySound
Copy link
Member

Hi! This cannot be implemented with current architecture. Though once we have own parser and ready for exposing set of utilities we will create new project specifically for linting to not mess the code with svgo. You can write here possible lint rules so we could rely on something in the future.

@techquestions
Copy link
Author

once we have own parser and ready for exposing set of utilities we will create new project specifically for linting to not mess the code with svgo

Is this work already planned and has some timeline? Please let me know if I can help make this happen (I mean code refactoring, not only writing lint rules here).

@TrySound
Copy link
Member

No really planning. I just improve things in my free time. So the best you can do for now is give some ideas. I'll ping you when something will be ready.

@GreLI
Copy link
Member

GreLI commented Mar 30, 2021

Well, there is an old idea just to optimize SVG, but don't save. Just tell whether it can be optimized with some threshold value. E.g. fail if it can be reduced more than by N% (but not less than M bytes, so don't bother about couple of bytes). I don't know though what values it should be. Something like 5% and 20 bytes for example? It should be configurable for sure.

@techquestions
Copy link
Author

Well, there is an old idea just to optimize SVG, but don't save. Just tell whether it can be optimized with some threshold value. E.g. fail if it can be reduced more than by N% (but not less than M bytes, so don't bother about couple of bytes). I don't know though what values it should be. Something like 5% and 20 bytes for example? It should be configurable for sure.

But the point here is to be able to return linting/validation in something that could be later used by other tools (like JSON reporter in ESLint). Right now it could only be console-logged.

@GreLI
Copy link
Member

GreLI commented Mar 30, 2021

I just don't know what do you want to be reported.
Maybe a dry-run which can say what can different plugins save? There is plenty of combinations though, maybe with a set of presets.
For invalid syntax it should be separate tool.
Maybe an option to report for things like fill-rule which can be safely optimized now automatically? (Due to complexity)

@techquestions
Copy link
Author

These are mostly some project-specific rules, not any invalid syntax. Something that a graphic designer would create but wouldn't match some standards.

For example: the artboard doesn't have proper size. This could technically be fixed using SVGO plugin but is not always something the user would want because it would actually required the SVG graphics to be fixed as well.
I was thinking about the dry run but still, there is currently no ways to get validation information except for parsing command line output.

@GreLI
Copy link
Member

GreLI commented Mar 30, 2021

Sounds like out of SVGO's scope. It's for an optimizing in terms of the file size in the first place, with a bit of image manipulating (for optimization purposes as well). I can understand optimization-related hints, but everything else should be done elsewhere.

@TrySound
Copy link
Member

@GreLI We are planning to expand the ecosystem of svgo a bit. This might fit.

@vanillajonathan
Copy link

Proposed linter rules:

  • title element must not be empty.
  • desc element must not be empty.
  • Container elements (g, svg, defs, metadata, etc) must not be empty.
  • text element must have text.
  • use element must have a href attribute.
    • href attribute must point to a valid id reference.
    • id attribute must be valid name according to the spec.
  • role attribute must a valid role.
  • aria-labelledby and aria-describedby attribute must point to valid reference.
  • Units must be valid units as defined in the standard.
  • There can only be one title element.
  • The title element can only be at the top.
  • Any indention should be consistent.
  • title should not exceed XX chars.
  • desc should not exceed XXX chars.
  • url function in filter attribute should point to a valid id that exists.
  • For encoding you probably want UTF-8.
    • Without byte order mark (BOM)
  • Class names in class attributes you probably want kebab case, i.e. lowercase with words separated by a hyphen.
  • Class names you might want to use semantic naming rather than presentational naming, e.g. text-danger not text-red.

@SethFalco
Copy link
Member

SethFalco commented Sep 7, 2024

For what it's worth, there is already tooling available that retrofits linting functionality on top of SVGO.

Found out about this while reviewing some conversations in ESLint:

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

5 participants