4 ms·

Must have VSCode extensions for Front end developers

16 points by ankit_m 7y ago

kzzzznot 7y ago
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.
- ankit_m 7y ago
  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.
- lindskogen 7y ago
  Why do you care about its style so much?
  - robjan 7y ago
    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).
    - LaurensBER 7y ago
      Run prettier on the entire codebase once and add an ignore-revs-file: https://git-scm.com/docs/git-blame#Documentation/git-blame.txt---ignore-revs-fileltfilegt https://git-scm.com/docs/git-blame#Documentation/git-blame.t...
      - WalterGR 7y ago
        How does that help? Genuine question.
        __initbrian__ 7y ago
        > 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
        WalterGR 7y ago
        > idk what the ignore rev file does Sorry - my question was ambiguous. That's the part that I don't understand.
    - tga 7y ago
      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 https://github.com/typicode/husky
  - kzzzznot 7y ago
    Because I find that its style reduces code readability.
- hombre_fatal 7y ago
  I've found that consistency trumps all aesthetic bike-shedding and hobby horses.
  - wayneftw 7y ago
    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.
- deleted 7y ago
  [deleted]
ankit_m 7y ago
Would love to hear about other extensions Frontend engineers use. Let me know in the comments :-D
ulucs 7y ago
Emmet is horrifyingly useful when you're typing html by hand. You may even forget where <, > and / are located.
stared 7y ago
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/ 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.
Kiro 7y ago
Do you really need autoprefixer nowadays?

16 points by ankit_m 7y ago

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.

ankit_m 7y ago
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.
lindskogen 7y ago
Why do you care about its style so much?
- robjan 7y ago
  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).
  - LaurensBER 7y ago
    Run prettier on the entire codebase once and add an ignore-revs-file: https://git-scm.com/docs/git-blame#Documentation/git-blame.txt---ignore-revs-fileltfilegt https://git-scm.com/docs/git-blame#Documentation/git-blame.t...
    - WalterGR 7y ago
      How does that help? Genuine question.
      - __initbrian__ 7y ago
        > 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
        WalterGR 7y ago
        > idk what the ignore rev file does Sorry - my question was ambiguous. That's the part that I don't understand.
  - tga 7y ago
    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 https://github.com/typicode/husky
- kzzzznot 7y ago
  Because I find that its style reduces code readability.
hombre_fatal 7y ago
I've found that consistency trumps all aesthetic bike-shedding and hobby horses.
- wayneftw 7y ago
  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.
deleted 7y ago
[deleted]

ankit_m 7y ago

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

ulucs 7y ago

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

stared 7y ago

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/ 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.

Kiro 7y ago

Do you really need autoprefixer nowadays?