Hacker News Reader

Comment by wwright | Hacker News Reader

Setting up eslint or related tools in a CI pipeline would let you catch these in an enforceable, consistent, decoupled way.

Of course, it sounds like there is no real testing or review before your team commits to master anyway, so there is your low-hanging fruit.

View on HN

It is an old project, setting up a strict automated CI would just block us until we fix all warnings or disable them. With a good IDE you can spot the issue int the location you work, you say change most of the "var" to "let" and "const" but you can ignore the ones that are not related with the thing you are working on. With an automated thing you either fix all at once or you have to set ignore rules or write ignore statements int he code.

I would be interested to read more on how to add such a strict CI to an existing project.

I'm sure you could get the linting tool to run only on changed files (we have a pre-commit git hook that does this at work, although we have CI set up to run against the whole codebase). To be honest though, I think the best approach would to pick a few of the rules you consider to be the most important and just be suck it up and spend a couple of days fixing all the errors. It likely wouldn't take you long to make that time back.

Agreed, but for sure having a CI with parts of the rule won't be as good as having that and on top an IDE that has all the rules On and even more you can see the warning as you type not after you committed and submitted a PR.

Well sure, but text editors like VS Code and Sublime can do this too. You usually need to install a plugin but everybody I know who uses these editors installs the relevant plugins for the languages they use.

VS Code is particularly smart in that will pull in TypeScript definitions for libraries and use those for auto-completion even if you are not using TypeScript (and are using plain JavaScript).

JetBrains IDEs do all of that stuff and more in my experience. Visual Studio Code plugins are a pretty basic IDE experience compared to them

This is definitely true. The tradeoff being that JetBrains IDEs are much slower (particularly to startup), much more resource intensive, and of course more expensive.

Startup time is bad, yes, but I think it’s a reasonable trade off for the features I get and plus I tend to launch it once and then open files with the command line tools, which is basically instant. Granted I’m spoiled on my personal machine with a six core i7, 16GB RAM, and an NVMe SSD.

> Granted I’m spoiled on my personal machine with a six core i7, 16GB RAM, and an NVMe SSD.

I think this makes a big difference. I also have 16GB RAM and a fast SSD, but I'm on a 2-core MacBook processor. I find that with all of the various different projects I have to interact with in a day (I'm the tech lead at my company) I can't leave an IntelliJ-based IDE open without it slowing the rest of computer down to the point that it's impacting my productivity.

I bet VS Code will be as slow if it could have the same features.

Well probably. That's why people accept fewer features in return for the speed.

What % of your work day is spent starting up projects?

IntelliJ rocks but you’re seriously underestimating tools like SonarQube and CI pipelines. If you’re working in a crusty old system, you will be blown away by the kinds of things they uncover out of the gate. “Strict” CI is all relative, one option is baselining your project, which adds suppressions everywhere that has errors, allowing you to track new violations and fix the old ones as you go.

I recently spent a day configuring SonarQube rules for Java and I'm not particularly impressed. It does not reveal much more than standard Intellij code analysis.

Also nice advantage of Intellij hints is that most times they also offer auto-fixer so it's very safe to apply the fixes.

If you have relatively modern code with reasonably good practices, sure. I ran it with the default rule set on a 15 year old C# codebase of about 150kloc and it found several quite serious vulnerabilities and a whole boatload of logic errors.

Did the conversation just go from "smaller is better" to "just use a CI pipeline to do the missing stuff"?

Every sufficiently complicated text editor and CI setup re-invents half of a good IDE, but worse.

These two do not conflict. It’s the Unix philosophy.

> Setting up eslint or related tools in a CI pipeline would let you catch these in an enforceable, consistent, decoupled way.

…minutes, hours or sometimes even days after the code was written. Not every project can run its CI pipeline in seconds, incrementally, or on the developer’s system.

The advantage of any IDE is the “integrated” part. Linting is one thing, showing the results in a way that makes it as easy as possible to act on them is where an IDE beats a DE that does the linting in a “decoupled way”.

Reply on news.ycombinator.com