search

openstyles / stylus

Stylus - Userstyles Manager
https://add0n.com/stylus.html
GNU General Public License v3.0
5.35k stars 302 forks source link

Stylus language and LESS linters #880

Open Mottie opened 4 years ago

Mottie commented 4 years ago

I received a request to either:

eight04 commented 4 years ago

Also this one: https://www.npmjs.com/package/postcss-styl

vednoc commented 4 years ago

Automatically disable stylelint when we detect Stylus language is being used

Yes, please! Some users that use my userstyles would complain about the linting errors, thinking it's the userstyle that has thousands of errors.

Add yet another linter - https://github.com/SimenB/stylint

While I personally wouldn't use this, I get why it's appealing.

IMO there are other issues with much higher priority that would better the UX of using Stylus, especially when you consider that majority of users don't write/modify userstyles, and those that do -- most of them don't use stylus-lang.

IMO userstyle authors that use stylus-lang should strongly consider using an external editor with stylus-lang extension(s) if they want to lint their code. I kinda experimented with it in the past and had to come up and stick to my own code style because the external editor performance was quite poor in both VSCod(e|ium) and Atom due to how large most of my userstyles ended up being.

Soitora commented 4 years ago

Disable stylelint by default when Stylus preprocessor is used would be soooo good, jesus christ I've had a lot of users complain or be scared but it's nothing wrong with what I've written :S

setyb commented 3 years ago

@vednoc

"when you consider that majority of users don't write/modify userstyles, and those that do -- most of them don't use stylus-lang."

What preprocessing language do you think is the most prevalent?

vednoc commented 3 years ago

Hey @setyb! All userstyles on USo-archive are converted to @preprocessor uso. Now, whether that is considered a language or not, I can't say with certainty, but technically it is the most prevalent one.

The other two preprocessors, Stylus-lang and Less, are languages. I've seen just a couple of userstyles using Less and over 100 userstyles using Stylus-lang. Majority of people that I know use Stylus-lang.

setyb commented 3 years ago

@vednoc Thanks for your valuable and helpful comment. (And sorry for the long delay in writing back... busy coding!).

I have written many custom styles (over 40,000 lines of CSS), and I wrote most of them in pure CSS without using a preprocessor. The ones that use a preprocessor were mostly using less, with a few using uso, and just 1 using 'stylus-lang`. Recently, I've thought about enhancing many of the various styles by adding preprocessor directives.

This is where your comment comes in, and I find your feedback to be very interesting. When I carefully examined uso preprocessor functionality, I found the functionality to be minimal and key functions to be missing. This isn't surprising (because as you mentioned, it's in the gray area between a language and a hack), but I ruled it out rather quickly. I do have a hunch that it may be the fastest preprocessor for Stylus to process, but someone like @tophf would probably be able to comment on that more accurately.

I then researched and learned less, and I liked how it is independent of the entire Stylus/Stylish ecosystem. That means the skills acquired are much more transferable. I found it's functionality to be quite good, although the syntax is not too great (being generous). I wrote several large styles using less, and they work well. I do have some concern about overhead with using less in large styles, but again, I think @tophf will be the best person to comment on that.

I then look a close look at stylus-lang. Wow, it's impressive, and it's hard to imagine that one or more people engaged in something so comprehensive that is largely unknown outside of a tiny group of people. Although stylus-lang offers much functionality, I didn't choose to embrace it because:

  1. I don't think the skills are transferable to anything outside of Stylus.
  2. I'm not sure if it's still being developed. It could be a "dead language". Currently, the https://stylus-lang.com/ server is completely down. That's where all the documentation was stored, the last time I checked.
  3. It didn't offer too much more than less, but required learning an entirely new language.
  4. As far as I could tell, any code using it will only run in Stylus (please correct if mistaken).

So that was my take, and my experience. I'm thinking of converting everything that will benefit from a preprocessor to less, but I'm interested in your feedback. Also, I'm interested in learning from @tophf or others:

  1. If a Stylus user has 100 large active styles, when is the preprocessing performed? Is it one time when the browser is loaded? One time when a matching URL is encountered? Multiple times?
  2. Does the answer to #1 depend on which preprocessor each style uses?
  3. Which is the fastest to process: uso, less, or stylus-lang? Do you estimate there be a noticeable difference with 100+ large active styles (500-25,000 lines of code per style)? If someone doesn't have a good guess, I might run a few tests, but that's going to involve investing quite a bit of time.
tophf commented 3 years ago
setyb commented 3 years ago

@tophf Thank you.

The uso preprocessor mimics the historical USO site's syntax (userstyles.org)

Yes, rather minimal functionality.

The Stylus preprocessor (stylus-lang) is a very well-known independent CSS language, its name is not related to our extension. AFAIK it offers much much more than less.

I had no idea it wasn't related. I guess the identical name is a coincidence. Has their website changed? Based on what you wrote, I would like to look at stylus-lang again, but their website seems to be completely down/gone: https://downforeveryoneorjustme.com/stylus-lang.com?proto=https

There's no overhead for applying styles when using any preprocessor because we compile them into pure CSS when you save it in the editor or when styles are installed/updated.

That's great news. That tidbit of info makes them all equal as far as speed for the user. Are they also recompiled at the moment a user changes a variable for a style in the Stylus toolbar dropdown?

tophf commented 3 years ago

Are they also recompiled at the moment a user changes a variable for a style in the Stylus toolbar dropdown?

Yes.

tophf commented 9 months ago

I think I'll implement a much simpler solution: compile the code in the preprocessor with sourcemap, check it in our csslint mod, which will be super fast as it checks only the changed rules, apply the sourcemap to the result. I'll probably also remove stylelint and reimplement some of its more useful and/or popular rules in our linter.

When the error mark is clicked the compiled code will be shown in showCodeMirrorPopup for easier debugging.