Accept syntax object in customSyntax option
#4839
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
14 tasks
mattxwang
approved these changes
Jul 1, 2020
|
m-allanson
added a commit
that referenced
this pull request
Jul 8, 2020
# By Richard Hallows (4) and others # Via GitHub * master: Create codeql analysis workflow (#4850) Update CHANGELOG.md Add support for descriptions in stylelint command comments (#4848) Update CHANGELOG.md Add *-allowed-list/*-disallowed-list/*-required-list names for *-whitelist/*-blacklist/*-requirelist rules (#4845) Update CHANGELOG.md Add syntax object acceptance to customSyntax option (#4839) Bump typescript from 3.9.5 to 3.9.6 (#4853) Add ignoreComments[] to comment-empty-line-before (#4841) Bump autoprefixer from 9.8.0 to 9.8.2 (#4838)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This overloads the
customSyntaxoption to also accept a syntax object. The option also maintains its previous behaviour of accepting a string. This should be a fully backwards compatible change.The signature of this option has changed from
stringtostring | { parse: Function }. This follows the convention of theformatteroption, which has similar behaviour.#3935.
This is based on a section of #4796. This is the only part of that PR that changes existing functionality.
The change itself is fairly straightforward, but it's probably worth detailing some of the why.
Why?
This API will be used to load non-standard CSS syntaxes (
scss,less,css-in-jsetc) when running in the browser.What is a syntax?
A syntax is typically an object containing two functions,
parseandstringify. Stylelint uses a syntax to transform your CSS-like code into a structure that can be linted, and then back again.Why do you need a custom syntax?
stylelint ships with syntaxes for linting the various flavours of CSS-like code that people use. These syntaxes won't be included in the default browser bundle as they are quite large - several MB for all of stylelint's included syntaxes.
What's wrong with using a string, anyway?
The
customSyntaxoption uses Node.JS'srequirefunction to load the syntax. It turns a string likemy-excellent-syntaxinto a 'live' JS module.requireis not available in the browser.Allowing the
customSyntaxoption to accept a syntax object means the host environment (whether a browser, Node.JS or something else) can deal with how to load the syntax, and then pass the object in for stylelint to use.