Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

[Discussion] Tokenizer enhancement for PostCSS-LESS Inline Comments

See original GitHub issue

I’m working to fix https://github.com/shellscape/postcss-less/issues/130 where the issue is that LESS supports single line comments such as // don't do this.., postcss-less uses the tokenizer from postcss which is unaware of inline comments. As a result of this quotes are tokenized as multiline strings when they are in a single line comment instead of treated as an ordinary character. I am happy to create a PR to add a feature to the postcss tokenizer to support this but I would like to discuss which implementation route would be preferred.

The way I see it the most “correct” change from a postcss-less perspective would be passing an option to nextToken to ignoreQuotes: true. I understand the ignoreUnclosed option was added for a similar reason. However I can also understand not wanting to have additional logic that would be currently exclusively used by postcss-less. I have an implementation of postcss-less which detects a inline comment token containing a multiline string, applies the rest of the line to the inline comment token and then re-tokenizes the remaining input: https://github.com/mattlyons0/postcss-less/commit/3a0e4d0914fa77d981afdaa13b57575e9d785e83 This PR is an acceptable solution if the ignoreQuotes route would not be ideal for postcss to adopt however in order to not waste CPU cycles tokenizing the remaining input (which the commit currently does) I would need a way to access the remaining input (which could be having the tokenizer return a function to get the input and the character the tokenizer is at). An additional route if you are opposed to ignoreQuotes would be to expose the ability to tell the tokenizer to go back x characters. This way I could re-tokenize after the end of the inline comment line without recreating the tokenizer.

I am open to any of these implementations, they are all fairly trivial implementation wise and this is more of a design choice. I’d be happy to implement any of them with tests once it is clear that the maintainers are open to it.