8
FracturedJson (github.com)
submitted 10 months ago by to c/javascript@programming.dev
5 comments fedilink hide all child comments
 

cross-posted from: https://lemmy.bestiver.se/post/837110

Comments

you are viewing a single comment's thread
view the rest of the comments
[–] 4 points 10 months ago (4 children)

My experience using it in a large project is seeing a lot of unformatted PR's, vs more mainstream tools like prettier etc. I think the main issue here is that the vscode extension uses separate config vs the cli/js version, and that there aren't extensions for other popular editors like jetbrains, zed etc. Also if you have a lot of projects that use json, and you want to adopt this in one of them, a lot of engineers are not going to bother setting up their env to handle different auto-formatting across workspaces. And some will say they prefer to run the formatting via cli then frequently forget to.

  • permalink
  • fedilink
  • source
  • hideshow 4 child comments
    •
  • [–] 2 points 10 months ago (3 children)

    pre commit hook and ci task. even with common formatters like prettier I do that on anything somewhat large

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 3 child comments
    •
  • [–] 3 points 10 months ago* (2 children)

    Yeah, but do you really want CI making commits in your git history? Haven't thought too much about it but I'm assuming it could get gnarly. In larger teams I often see stuff that could not possibly have passed the existing pre-commit hook. Actually on one of our projects the unit tests run on precommit and it takes 8 minutes on my machine, so you could call me a git hook skeptic.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 1 point 10 months ago (1 child)

    No, CI validates that the hooks or formatter ran, and fails if not. in theory it shouldn't ever fail but it's to catch the stuff that couldn't have passed the commit hook.

    the hooks are easy to turn off and can be hard to get to reliably run (90% of the time they're fine, but all of the tools that run git commands sometimes do weird things), but they're a best effort kind of thing.

    unit tests on precommit are a little annoying, especially when it takes that long. that's better suited to running in ci afterwards since there's no advantage to running before you commit. formatter takes like 200ms max for affected files? you won't notice, and it ends up as part of the one commit

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 1 child comment
    •