Everyone's obsessed with picking the "best" formatter plugin. But they all silently fail the same way. Your prettier/eslint/stylelint step passes green while your code's a mess. Happens in Jenkins, GitHub Actions, whatever.
Check the obvious first. Did it actually run? Look at the step logs for processed files. Zero files? Your glob pattern is probably wrong. The plugin ignores missing or empty matches by default. Classic. Also check the working directory. Your `**/*.js` means nothing if you're in the wrong folder. If it "ran" but changed nothing, check your ignore files (.prettierignore, .eslintignore). They override your config.
Pipeline as code or go home.
Oh, the working directory one gets me every time in CI. You think you're running from the root, but your step is actually executing inside a `./frontend` subdirectory because of a prior `cd` command you forgot about.
Another silent failure I've hit: caching. If your CI caches node_modules or even the formatter's own cache directory, and a dependency update goes sideways, it can fail to process files but still exit with code 0. Always worth adding a `--no-cache` flag or clearing it as a test.
Ever run into the "formatted with itself" issue, where a prettier update changes its own output format and then all your files are suddenly "wrong"? The step passes because it formatted them to the new standard, but your git diff explodes.
DataDogDodger
Absolutely, those ignore files are such a tripwire! I'd add that it's also worth checking the *precedence* of those configs. In a monorepo setup, you might have a `.prettierignore` in a sub-package that's overriding the root config you *think* is being used. The plugin runs, respects the local ignore, and changes nothing - leaving you baffled.
And on the glob pattern point, I've seen teams use `src/**/*.js` but their build step outputs transpiled files to `dist/`. The formatter runs on source, passes, but the actual deployed code is a mess. It's a mismatch between the formatting target and the final artifact.
Another trial, another spreadsheet
You're focusing on the mechanics but missing the security angle. If a formatter plugin fails silently and passes green, what else in your pipeline is doing the same? You've got a broken control.
Zero processed files could mean your glob excluded a directory with vulnerable legacy code. Now it's not getting formatted, not getting linted, and definitely not getting scanned. That ignore file you mentioned could be hiding a whole folder of dependencies with known CVEs.
Silent success in tooling creates a false sense of security compliance. Your audit trail shows a passed step, but the actual code state is unknown.
secure by default, not by audit
You're right about the basics. But focusing only on the log output can still mislead you. If the tool runs on a single file and passes, the step looks successful. The real failure is assuming "processed files > 0" equals "processed the *correct* files." I've seen pipelines where a single config.js file gets formatted, logs show one file processed, and everyone moves on while the app directory is untouched. The logs didn't lie, but the intent did.
> "processed files > 0" equals "processed the *correct* files."
That's the dashboard problem! You see a green checkmark for the "formatting" panel and assume coverage. But you need a metric for *expected* files vs *actual* files. I've started adding a simple script after formatting that counts files matching the source glob and compares it to the tool's reported count. If the diff is > 0, the alert fires.
It's a cheap sanity check, but it catches those "single config.js" scenarios every time.
If it's not monitored, it's broken.