Must have VSCode extensions for Front end developers | Hacker News Reader

Must have VSCode extensions for Front end developers

sharelist.co

16 pointsankit_m16 comments

I dislike prettier, imo it is too aggressive all around. I understand the lack of configurability is intentional (to force consistency on a macro scale) but I don’t like its style. Anyone have any good experiences with a more configurable formatter? Looking for one to adapt to existing coding style in a several years-old multi-application project.

I've found that consistency trumps all aesthetic bike-shedding and hobby horses.

It’s not consistent. The worst thing about “prettier” is how it constantly flip flops back and forth between a single line or multiple lines for imports, destructuring and JSX tags.

I will jump ship the second something comes along that respects line breaks.

Even I find it annoying many times. I disable it for all my personal projects. But I have found it to be very helpful for larger projects which has contributions for a large number of developers. It helps reduce unnecessary discussions around styling which people will disagree on all the time.

Why do you care about its style so much?

Because I find that its style reduces code readability.

It's a bit annoying when you have a large project then someone introduces prettier. Suddenly every pull request has dozens of random formatting changes everywhere and it obscures the actual changes. It also completely nullifies the functionality of git blame (I know there are other ways to see the file history).

Run prettier on the entire codebase once and add an ignore-revs-file: https://git-scm.com/docs/git-blame#Documentation/git-blame.t...

How does that help? Genuine question.

> running it on the entire codebase

The autoformatter config file is checked in with the PR that’s runs it on the entire codebase. Everybody’s machine autoformats the same way.

Only things that are changed in the PR will be formatted along with the PR.

The separate problem I’ve found is any outstanding PRs at the time of running it on the whole codebase should merge in the commit before the format all, then the format all change, then current master. It’s made resolving the PR merge conflicts easier

idk what the ignore rev file does

> idk what the ignore rev file does

Sorry - my question was ambiguous. That's the part that I don't understand.

The best way to introduce a formatter is with a git hook on commit/push (for JS projects see Husky), to ensure everyone is onboard and avoid exactly the formatting churn you mention.

Thanks LaurensBER for the ‘git blame’ solution!

https://github.com/typicode/husky

I am not sure what it does here.

On VSCode there is a nice recommendation system, based on file types and vox populi (so one can see if other people use it). I wish other pieces of software hard it as well. (For Sublime Text there is https://packagecontrol.io/, but it requires checking with an external website.)

...

As a side note, do you know if there is a VSCode REPL for TypeScript? There is the console, but it is static in the sense - once can run the whole file. I have a lot of experience with Jupyter Notebook for Python, and it is a kind of tool that for some prototyping (especially in numerics) makes things orders of magnitude faster to detect, and fix, errors.

Would love to hear about other extensions Frontend engineers use. Let me know in the comments :-D

Emmet is horrifyingly useful when you're typing html by hand. You may even forget where <, > and / are located.

Do you really need autoprefixer nowadays?

Reply on news.ycombinator.com