[Feature Request] Build a Less linter that uses the Less parser (Rebuild the parser)

[avaly]

I am looking for a tool for LESS that does what node-jscs does for JavaScript. It would be useful on project with large teams to enforce a code style throughout the LESS files. I could not find any such tool on npm.

I guess the only technical aspect blocking one from using the LESS Parser from this package to build such a tool is that the Parser discards all whitespace information when building the tree. Otherwise, if one were to build a code style tool one would have to write a new parser for LESS.

I propose an optional setting for the Parser that would make it save the whitespace information in the tree.

Hopefully others out there would use such a tool (LESS code style checker).

[seven-phases-max]

I'm afraid this basically means "write a new parser for Less". Currently neither parser nor the syntax tree it generates support "saving whitespaces" so you'd have to rewrite almost everything from scratch to achieve this.

[akshaypundle]

I was looking for something like this as well .. a less style checker would be valuable in a large project.

[avaly]

Could this feature be considered for a bigger update, such as the upcoming 2.0.0 version?

I feel this is quite important for the LESS community.

SASS has such a code style linter tool already: scss-lint

[lukeapage]

You wouldn't have to rewrite the parser. On the 2 branch I was thinking
about making the parser create each node and set indexes. I was also
considering storing the whitespace (including comments) as it was skipped
over and auto attaching to nodes. However I didn't go that far (it auto
skips comments and the picks up all comments next time you ask) because
it's so difficult to know where whitespace should be stored. E.g. end of
rule or start of rule? Value or expression?
At the moment we store an index at the start of each parse attempt and then
apply to the node when created.. if that could be automated I think we
could also attach whitespace information (including comments) as well
(possibly duplicating between nodes and used as needed?)

Anyway, I don't quite know how to do it, but I'd like to think it's
possible and I'd like to see it happens. However you're right Max that it
isn't a small bit of work.

[davidtheclark]

Adding my interest in this to the thread. I was considering using the SUIT preprocessor instead of LESS specifically because of its Rework-based conformance checker. The possibility of building such custom tools is very appealing.

[anshumanf]

I'd love to collaborate in any effort to get this going. My ultimate goal would be to develop a linter for LESS that allows pluggable rules, a la eslint.

[SomMeri]

@anshumanf Welcome :), it would be useful thing. Did you started somewhere and do you need some concrete help?

[davidtheclark]

I've been working on a pluggable PostCSS-powered linter: https://github.com/stylelint/stylelint. I wonder how it might work for Less. We've been working a little bit already with non-standard syntax features (e.g. nesting) --- but they have to be syntax features that don't make PostCSS error --- and I think that many possibilities will open up after @ai enables custom syntaxes in PostCSS ... Just something to consider, maybe experiment with, if anyone's interested.

[anshumanf]

@SomMeri It's early days yet. So far I'm still figuring out the LESS parser and my plan of attack. Will try to get back with something concrete soon. I'm glad to see there is still interest for this. :)
@davidtheclark Looks interesting. Very much in line with what I'm looking to build. I'll check it out.

[ai]

Yeap, next release PostCSS branch already can replace a parser. I think we will have a basis SCSS and Less parsers in next month.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[matthew-dean]

Re-opening this as there's still ongoing interest for a Less-based linter. - See: microsoft/vscode#43087 and especially this comment: microsoft/vscode#43087 (comment)

I've been doing experimental work from time to time on a Less parser replacement which could possibly help with linting (and preserving whitespace) eventually - https://github.com/matthew-dean/less.js/blob/experiments/parser/lib/less/parser/grammar.ne

[octref]

@matthew-dean
Would it be better to integrate with Stylelint instead of trying to start anew? From my understanding, PostCSS digest all scss/less/css/postcss into a common AST and operate on that, and Stylelint uses that AST too to generate errors. Last time I looked, @ai has this parser https://github.com/postcss/postcss-safe-parser, and it seems stylelint is using it.

But for linting in editor, your parser needs to be

• Error tolerant. See https://github.com/Microsoft/tolerant-php-parser#design-goals. That's a lesson we learned when we were trying to improve PHP support in VS Code. An incomplete part in middle should affect linting the rest of the document
• Ideally it should also be fast for re-parsing. As the user is typing, he hopes the linting errors can be shown / invalidated as fast as possible.

[matthew-dean]

@octref I agree that (integrating with Stylelint) should probably be the short-term solution for VSCode.

[octref]

@matthew-dean Does that mean you are planning to build something better for Less specifically? 😛

[matthew-dean]

@octref Ha, me specifically? No, I'm mostly focused on bug-fixing & new Less features right now. I've done some parsing / linting explorations, and am talking to someone about taking on that work, so the most I'd probably be involved in something like that is either in helping manage or coordinate the work.