Stylelint – A modern linter for CSS

Not really. TypeScript providea much stricter checking than just checking that I have the correct syntax. Whereas this tool isn't checking that my combination of CSS properties makes sense, it's just checking the syntax...

It's relevant information, because not everyone uses the same postprocessing pipeline as you do (or even any at all)

Until now, the variants where #rrggbb and #rgb, so the extension to alpha is parallel: #rrggbbaa, #rgba. I personally like that extension, so you can just add an alpha component to a color without transforming it to a different form first. It's also relevant to people using automated systems, since those automatically can choose the most compact representation of a color possible in their output.

> This is a spec going through draft-review-deployment so we can type 3 less characters?

The key phrase above is is part of, it's one of the smaller aspects of the spec.

This doesn't have anything to do with variables, it's simply adding an opacity value to hex-encoded colours. So `#ffff` (or `#ffffffff`) is the sames as `rgba(255, 255, 255, 1)`, and `#ffffff7f` would be `rgba(255, 255, 255, 0.5)`.

Until now, if you wanted to assign a colour with opacity, you had to use the `rgba()` format. Now you can just hex-encode it :)

The only thing lacking about Stylus is the documentation really - the built-in functions page seems to list functions in random order (could be in order of addition to the language I guess!), there's no master index of the various syntax features, its usefulness varies a lot between different features - some are barely mentioned at all - and stuff like arrays, lists and hashes could do with more clarification.

Actually, looking at some of my standard Stylus includes, you can't have a block mixin that modifies the individual rules in a block, to be able to create something like

  important()
    for $prop, $value in block
      {$prop}: $value !important

I recently discovered a new user style Chrome extension called Stylus after Stylish was removed from the Extension Store for privacy violations, and not only does it allow you to use Stylelint and CSSlint to check your user styles, but it supports an extended type of user style called UserCSS that allows you to use Stylus for writing styles :) It does need you to use colons to prevent the editor and Stylelint complaining, but everything else works:

https://gist.github.com/spiralx/8c547d48cfaa0628ee720a16caaa...

And that's why I tried to avoid saying it's a bad idea in general.

I'd love to see more diversity in languages on NPM. Things written in Go but compiled and distributed as binaries over NPM (maybe with a small JS wrapper), or things written in Rust but compiled to wasm and distributed over NPM.

If the compilers in those other languages get a bit better at outputting WASM or JS, we get closer to the idea of being able to really use the best language/tool for the job, then cobble them all together near the end to make one truly great product where each part is written in a language which is best suited to the sub-task it's doing!

Agreed on WebAssembly... I'm thinking/hoping that a number of binary packages will be migrated to, or at least tested via webassembly. There are some modules in C that are impossible via webassembly, but a great number of them are.

Having the wasm versions in npm could be really useful.

But it was again rewritten in Dart and the Dart version is now the reference implementation. And they did that because for a lot of Sass users, working with Ruby sucked, simply because they didn't have the tooling and knowledge built up to handle it correctly.

Libsass's main "claim to fame" is that just about all languages (including Javascript on the backend) can interop with C/C++ pretty effortlessly. The rewrite was more about enabling more and more users to use the languages and package managers they are used to rather than about speed (especially since the Dart SASS implementation is quite often FASTER than the libsass version!) Take a look at the Sass perf benchmarks below for more info:

https://github.com/sass/dart-sass/blob/master/perf.md

Although keep in mind that a lot of the performance benefits go away when you run Dart Sass via javascript compilation in regular node. But IMO that gives you a lot of choice. You can get the best performance by installing the Dart toolchain and running it "natively" on dart, or you can run it via node for "okay" speed in most cases, or you can deal with native compilation via C/C++ and libsass for a mix of both. It's a nice setup they have going on over there!

But when 99% of your target audience (in this case JS and web developers) already have the runtime installed, then "just copy a binary" isn't easier, it's harder.

`npm install stylelint` is about as easy as it gets. copying a binary requires you to put it somewhere, make sure your path is setup correctly, find a way to automatically install it (or put it in the repo causing the size of the repo to bloat), and ensure you are downloading the right version for each platform.

And you still didn't address the other issues. How do you know when it has an update, or a security update! NPM warns you if the author deprecates a package version with big yellow warnings when you do something letting you know it's unsupported and has security issues. A binary won't do that.

And then you still have the issue of being unable to modify the code, or even see the code on your system.

And "much better code" is subjective as hell! Go sucks to work with and read for some because it's a bit verbose, especially when dealing with errors and some of the hoops that have to be jumped through to handle or make generic functions. Rust is a HUGE language IMO, I've never used it professionally, but I've been trying to learn it and every single time I see a rust codebase I'm looking up new syntax or some other feature I didn't know about. That's not to say those are 2 bad languages, but that all languages have their downsides. JS is no different, but again when your target audience is 99% devs that use JS on a daily basis, other languages, no matter how easy to understand and use, are going to be harder to work with for them.

I'd love to see more diversity in this area, but if you are telling me to "download and run this binary" as the install method, it's probably not going to be included in an app that I manage, because there's too much extra work that has to be handled, like installing it automatically on the CI server, installing it locally for devs, keeping it up to date, checking it for security issues or problems (if the dev even reports them), and a lot more.

Having to copy a binary is a downgrade. NPM is an xplat distribution platform.

The majority of projects that would use this already use NPM to version their other tools/linters/formatters like eslint and prettier. So now this one tool doesn't integrate with their tooling. For very little upside beyond appeasing a few people on HN.

When you build something, you have to think about more than just your idea of absolute technical superiority. Distribution and toolchain integration and an understanding of your end-users are just as important. Also, would they have the same plugin ecosystem if they hadn't used NPM nor Javascript? https://stylelint.io/user-guide/plugins/

> 1. Easier distribution (like I said, just copy a binary)

I'm not sure how your system is setup, but most of us already have npm installed and using a package manager is about as simple as it gets to distribute tools. Since it's on npm you don't have to worry about apt, brew, or yum distributions. Just the one that is already installed on everyone's machine who will probably be using this, regardless of stack or OS.

Your other 2 points are moot. You don't get to pick the tools of other projects.

Indeed, requiring Ruby to build SCSS files used to be a pain.

Every other part of our toolchain was done via NPM. You could install all of it in seconds via one command... and then people had to hunt the correct and compatible Ruby binaries for their system.

Our .NET developers on Windows hated this. "Why do I need to install Ruby to build your front-end?!"

Dart Sass was a godsend.

Unfortunately, we live in a free society where I need to base all my actions on keeping myself employable. This means I'll spend 4 hours writing a small tool in JS instead of 1000 hours trying to learn semantic modern c/c++/rust/golang. That's 990 hours I could spend making more tools, learning new technologies that employers would find relevant on my resume, or spending time with friends and family.

No it's not. The problem is you're grossly misinformed about languages in general (a more suitable language? wtf?). There's nothing wrong with NPM and distributing packages used by the majority of the ecosystem. And for all of NPM's problems, it works literally better than every other garbage package manager. But I suspect your criticism is more because you read some comments about NPM, not that you know what you're talking about.

I kinda agree about JS CLI tools. However, I'm guessing the target market is JS-led front-end developers. Installing via npm makes it simpler to drop in to a toolchain that's already oriented around npm.

Not saying that's right or optimal, of course.

Could you expand on why you use gulp-shell when you presumably have the ability to run shell scripts directly?

Anyone who actually takes the time to lint their styles will likely have a customized build system.

This is not aimed at the person with no experiences who make static websites using notepad in their free time. This is aimed at people who already have their hands deep in the front-end ecosystem.

You're a "web developer" and JavaScript is not something you're familiar with?

They still need to install Node. This is just a zip file that Node would run that contains all the dependencies inside the zip.