Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

GitHub Super Linter: one linter to rule them all

github.blog

Post reply on HN
Print view View original

301–310 of 360 posts

Re: GitHub Super Linter: one linter to rule them all

#301

Post by Dylan16807 »

iso8859-1 wrote: post #285
jlarocco wrote: post #261

Earlier quoted context omitted.

I suspect you're probably right, but that example isn't the greatest because Python 3 isn't source compatible with Python 2. The source code text itself isn't even backwards compatible in that case.

Since even minor releases can introduce new syntax that previously failed to parse, this happens more than just on major version numbers. For example: async/await, formatting string literals, underscores in numeric literals, the list goes on and on. So you'll have to upgrade your formatter. And when you upgrade it, it may start formatting something differently than it previously did, even if that chunk had no new syn…

Use one that won't change how it formats on a whim?

Re: GitHub Super Linter: one linter to rule them all

#302

Post by Dylan16807 »

philsnow wrote: post #282
jlarocco wrote: post #261

Earlier quoted context omitted.

I suspect you're probably right, but that example isn't the greatest because Python 3 isn't source compatible with Python 2. The source code text itself isn't even backwards compatible in that case.

That was maybe not a great example, pick any language change where a new keyword was introduced that wasn't previously a keyword or reserved word. I tried to make an example with `with`, because that was introduced between 2.4 and 2.5 IIRC, and 2.4 and 2.5 aren't nearly as far apart as 2.* and 3.*, but I didn't find an easy way to install a 2.4 python (it didn't compile in pyenv on my mac, and I looked at a couple do…

But you're describing a benefit of storing an AST. Instead of the code suddenly changing meaning, you have an AST that says what the meaning should be.

The worst case is that you export it with the old version of the converter, and then the code changes meaning. You have silent corruption. But if you stored raw text this would always happen.

The good case is that you export it with the new version of the converter. It will notice that a variable name matches a keyword, and alert you to fix it.

Re: GitHub Super Linter: one linter to rule them all

#304

Post by tlrobinson »

waheoo wrote: post #279
crooked-v wrote: post #275

Earlier quoted context omitted.

> It decides to undo your work What you're missing here is that you're supposed to be using it all along, all the time. Format on save. Format on commit. Format on server pipelines. Format all the time. It can never 'undo' anything if it's what's providing the formatting in the first place.

Thats what im talking about. If you add text to a line, and it goes over a length, it will reformat a jsx element into about 5 lines instead of 1. Similarly, when you add more than it needs because you want consistency, or know youll add more, and the formatter runs, often it undoes your work.

Prettier lets you control object literal formatting by inserting/removing the newline after the opening brace, I'm not sure why they don't do that for JSX elements.

https://prettier.io/docs/en/rationale.html#multi-line-object...

Re: GitHub Super Linter: one linter to rule them all

#305

Post by tlrobinson »

l0b0 wrote: post #177
tlrobinson wrote: post #167

Earlier quoted context omitted.

This is basically solved by pinning the formatter to a specific version in your project's dependencies, and enforcing its use in continuous integration. Of course that doesn't help if you're setting up the formatter for the first time, or want to upgrade to a new version. Some tools like GitHub's diff do try to deemphasize whitespace but it's pretty limited.

In easy steps (Python/Git specific): 1. Use a tracked directory for Git hooks: `git config --local core.hooksPath 'git-hooks'`. 2. Create format.bash and lint.bash. 2.1. Run `black` and `isort` in format.bash. 2.2. Run `flake8`, `mypy`, `black` and `isort` in lint.bash. 2.3. Run lint.bash in the pre-commit hook. 2.4. By default, lint/format only files which are different from origin/master to save time: `git diff --d…

Even better, IMHO, is just setting your editor to format on save. That way you can just write ugly code and hit save to get it formatted.

I've found git hooks to be more trouble than they're worth.

But as long as it's enforced in CI you can leave it up to individual team members how they want to do it.

Re: GitHub Super Linter: one linter to rule them all

#306

Post by Vinnl »

kristopolous wrote: post #206
Vinnl wrote: post #194

Earlier quoted context omitted.

Could it be that the problem with the linters you've experienced was that they were just configured far too strictly about things that don't matter too much, rather than linting itself being the problem? I've got my linters set up pretty loosely, but the things that are enabled have definitely helped me detect bugs earlier and quicker, and I really don't see how anyone could be against that.

well sure. There aren't bad tools just bad practitioners, sure. Certain tools give more affordance to certain use cases and maybe that's the issue. For instance something where I am the culprit would be in PHP. I like PHP. I think it's a convenient and powerful language. Someone could take my linter arguments and weaponize them against PHP because it's too easy to do terrible things with it. Then I'd be the one on th…

Yep, I can definitely agree there.

That said, I'd argue against strict stylistic rules, not against linters in general. For example, the common Javascript linter (ESLint) has a setup wizard that allows you to choose whether you just want to check for bugs, or also enforce style conventions, and will enable a predefined set of rules depending on your choice. The bug-spotter is the one that's preselected. This is a very reasonable approach to me.

Re: GitHub Super Linter: one linter to rule them all

#307

Post by Vinnl »

lowercased wrote: post #193
Vinnl wrote: post #114

Earlier quoted context omitted.

What do you dislike about bugs being highlighted as you type, rather than first having to run your code?

> What do you dislike about bugs being highlighted as you type many things "highlighted as you type" aren't "bugs". let greeting = "Hello " + user.name; Auto-fixing immediately flags this with "DAMN YOU USE A CONST!!!!" (multiple red squiggles that I have to hover and review). but... I might be making a change to it a few minutes later... but I've got some damn visual shit flashing in my eyes that "USE A CONST" conca…

So the problem is having rules enabled that do not help prevent bugs. Actually running ESLint for the first time will ask you if you just want to check for bugs or also enforce some code style. The former is preselected, and would not shout at you for not using `const` or template strings.

I'd always argue for using it that way, which is very reasonable to me.

(A bit weird to have 30 years of muscle memory writing `let`, btw :) )

Re: GitHub Super Linter: one linter to rule them all

#308

Post by vages »

earthboundkid wrote: post #298
waheoo wrote: post #279

Earlier quoted context omitted.

Thats what im talking about. If you add text to a line, and it goes over a length, it will reformat a jsx element into about 5 lines instead of 1. Similarly, when you add more than it needs because you want consistency, or know youll add more, and the formatter runs, often it undoes your work.

If you really want 5 lines, add a dummy // in there and will be forced to use 5 instead of 1. Dirty hack, but it works.

That, or a prettier-ignore comment above the JSX tag. I find your solution more elegant, though.

My two cents: Write the comment's purpose inside it. "// Comment inserted to force prettier line break until more attributes are added"

Re: GitHub Super Linter: one linter to rule them all

#310

Post by OkGoDoIt »

tlrobinson wrote: post #37

Great! Now do it for code formatters! After using Prettier for a few years I'm firmly in the camp of mandatory/enforced code formatters. As long as it's a half decent formatter like Prettier I believe my personal opinions on the specific formatting choices are much less important than essentially never having to think about formatting again, in particular having to ask people to fix formatting in code reviews (or fix…

That would be great if I actually worked on a team who saw the light and used tabs. Unfortunately I haven’t had that pleasure in a long time, so no, I do not agree with their formatting choices to use spaces. I guess what I really need is an editor that will convert spaces to tabs when I open a file and then convert it back to spaces when I close the file. Although that’s still not quite ideal because it’s not always a lossless 2-way conversion.
Post reply on HN