Run Prettier in a Container

Adopting Prettier in an existing medium sized code base

Georgi Parlakov
2 min readJan 31, 2019

Container == Docker container

Turns out some shells do not expand ‘**/*.*’ to what one might expect i.e. all files in all sub-folders recursively. Using something like ‘**/**/**/*.*’ is the workaround — in this case all folders up to 3 levels deep.

So I wanted to run Prettier on all of our source files (Why? See * below). And since it does edit all source files I wanted to do it in a way that we could test the result before committing. To that end I chose to run that in a container i.e.:
- copy all source files in a running container (to isolate from production source files)
- run Prettier on them
- run a build and get resulting artifacts (we do Angular so ng build --aot resulting in js,html and css)
- deploy the result and get our QAs help in verifying all works.

But when Prettier ran in container it only processed a few files and stopped:

prettier --write **/*.*

First thing I though was — prettier has a bug. And it does — an issue that’s closed:

It can’t be fixed because it’s actually due to shell not ‘expanding’ **/*.* as expected. That is Linux shell i.e. bash. And as this comment suggests:

Workaround is to use a ‘deeper’ pattern. For example ‘**/**/**/**/**/**/**/**/**/**/*.*’ will go 10 levels deep and give all files.
Note: Turns out you don’t need to specify **/*.* then **/**/*.* then … up to 10. The 10 levels deep one gives all files from all folders starting from current up to 10 levels deep. That’s what we used.

We like having the opinions of Prettier and use it to keep the small-time arguing for tabs vs spaces to a minimum. Trying to adopt an if-you-can’t-automate-it-don’t-force-it attitude to our code base.

(*)The reason why run prettier on all files is simple. We run an Angular app and had some styling inconsistencies. So we decided to adopt Prettier and run it on the new and edited files. And the edited files were very difficult to review — imagine 1 actual edit resulting in a whole lot of red-greed in the PR diff. On multiple occasions I had to ask the author to specify where are the actual changes were because there were files with hundreds (~200) changed lines of whitespace, commas and new lines and 2 actual changes. That’s why I wanted to try to run Prettier on all files and make reviews much easier.

--

--

Georgi Parlakov
Georgi Parlakov

Written by Georgi Parlakov

Angular and DotNet dev. RxJs explorer. Testing proponent. A dad. Educative.io course author. https://gparlakov.github.io/

No responses yet