SassC is just a cli tool that uses the C-language SASS library. It's an alternative to using whatever ridiculous NodeJS solution was/is being used.
You don't need to assume, npm has an audit command that helps figure out if any of your package dependencies have reported vulnerabilities: https://docs.npmjs.com/cli/audit
Does Go?
No, Golang doesn't, but then it doesn't have a registry like npm in the first place. Gophers tend not to use third-party libraries if at all possible.
That sounds weird to me. It's pretty rare (almost never?) for applications to do useful things without third party libraries. eg any database access, input validation, making sure HTML output isn't malicious, etc.
Maybe that's just me though?
There's also a set of "semi-official" libraries for things like crypto that can't be written by amateurs ;)
There are some other libraries that are commonly used, but you can count them on one hand.
I'm a massive convert to this. Instead of spending my time working out how to get two 3rd-party libraries to talk to each other, I spend my time writing domain-specific code. and my debugging time is spent in repo's that I have a hope of understanding because I wrote them ;)
It doesn't suit everyone, and there are frequent rants on golang forums about people not importing dependencies. But every gopher seems to go through the same journey, and end up at a place where they just write their own code rather than importing it.
Just got sassc working instead, so happy again hehe
I've just spent yesterday getting sass to work with my Golang project.
I used to have a nice simple makefile task, that compiled the project (in a split second) and launched it on localhost so I could find out where the problems were. My only dependency was the Go compiler. If I changed the css, the next page refresh sorted it.
Now I have a "sass watch" task, which compiles the scss to css. But that requires node.js, and npm (there are golang scss compilers, but all of them are either not being maintained, or have problems, or only support older versions of scss). I have to run this in a separate terminal so I can stop it when I need to.
I've deliberately not looked at my global node_modules directory. If I don't look, I don't have to worry about how many js libraries just got installed on my machine, and I don't have to think about who's maintaining them, and if they're now malicious. As long as sass only touches the css files, and css isn't Turing-complete (yet), then I don't need to audit any of that, and I can assume that it's not injecting malicious code into my application.
Though there are possible attacks on my site that could originate with code injection from a $malicious_left_pad js library, even via css, but it's enough of a stretch that my paranoia can live with it. I can check out the compressed css every now and again and see that it's not importing anything it shouldn't, and be reasonably sure that I haven't just compromised all my users' security.
So yeah, it's not so much that a preprocessor is a complication, it's that a preprocessor allows a malicious package to compile whatever it likes into files that I will then serve from my domain to my users, who trust that I'm not serving them malicious files. That's policed not at all by npm, or any of the package managers, who cheerfully assume that all javascript developers are honest.