4 ms·
Yeah, all the the cool kids do prettier with husky. We do prettier with husky. New webstorm will have prettier integrated so I can throw away my external tool c
by xab9 9y ago
Yeah, all the the cool kids do prettier with husky. We do prettier with husky. New webstorm will have prettier integrated so I can throw away my external tool command for that. Well, probably if `eslint --fix` worked _properly_ (and all the plugins would implement their fix part) we would not need yet another tool, but whatever...
On the other hand my problem with modern frontend is that fifteen years ago compiling a fairly complicated desktop app and then commiting it to cvs took a couple of seconds (not that the two are related of course). Now webpack cold start is one minute, hot recompilation is between 5sec and 50sec, prepush hook tests a minute or two (and then it is still lightning fast, approx 2k tests in pure jsdom), add prettier, eslint, stylelint, ticket id check to precommit hook and then boom.
We tried to turn stuff off in feature branches, but it seemed to be a bad idea... also note that we're a mixed environment with win, osx, and linux machines and on windows webpack/mocha watchers tend to lock some files randomly, so there is a good chance that someone will choke on a locked file (the ide, git or webpack itself), so I gotta power down the whole thing for branch changes or test watchers.
- tlrobinson 9y agoI prefer having my editor run prettier on save, so I get the benefits of prettier formatting my ugly code immediately. Also, lint-staged doesn't handle partially staged files properly: https://github.com/okonet/lint-staged/issues/62 https://github.com/okonet/lint-staged/issues/62
- xab9 9y agoI tried running it on save, but I can't "make" others configure their editors in a way I want (our fe team is around 10 ppl, be is much bigger). Lint-staged can't handle partials, but precise-commits can, though we are using ls for now and will see how much this hurts in terms of partials.
- tlrobinson 9y ago> I can't "make" others configure their editors in a way I want We run `prettier -l` in CI, so it's up to each person to decide how they want to make sure their code is prettier-ed before being pushed. I'll check out precise-commits, thanks.
- matthew349hall 9y agoWhy not use gulp-watch or equivalent build tool in your stack somewhere so everytime a file is saved it gets ran through prettier?
- saranshk 9y agoTotally agreed. The pre-commmit hooks do tend to have a lot of tests and enabling in feature branches will be a pain but these tools are needed in order to have stricter checks and ensuring that people of all experience levels continue working without destroying the code quality
- tokenizerrr 9y agoHow do you get people to configure the pre commit hook consistently? As far as I know this can't be done automatically, right?
- saranshk 9y agohttps://prettier.io/docs/en/precommit.html https://prettier.io/docs/en/precommit.html This should help you get setup
- jcbrand 9y ago> all the the cool kids do... Am I alone in being annoyed by this phrase? Most of us here are grown adults, not 14 years old and this isn't high-school anymore.
- xab9 9y agoMaybe. I'm close to fourty and to the sixty year old guy in the cafeteria I'm a kid (he literally callse me that, I just chuckle about it). Sorry if it offended you, meant no harm - maybe little sarcasm about how fast frontend tech moves these days, but that's all.
- VMG 9y agono docker? amateur
- xab9 9y agoNo docker here and it hurts us, but it's just impossible to get the cms and core backend into docker containers. I heard all kinds of smartypants recommendations from yes you can to look for another job. Whatever.
- bichiliad 9y agoI think no one's arguing that, if your project calls for it, you could just write javascript and commit it to a repository and be done about it. All these tools just add guarantees to the quality of code in a codebase so that it's easier for a lot of people to work on the same app. Is it slower? Sure. Is it worth it to keep from deploying bugs? Also probably sure. As a side note, I'd argue that running tests should probably not block you from committing code, but it should keep you from deploying code. I work at a company where our hooks are (usually) pretty fast, but keep you from having to rerun a much larger test suite.