`yarn lint` in agoric-sdk failing with mysterious error
See original GitHub issueDoing a yarn lint at the top, I got

The only mention of “lint:format” seems to be https://github.com/Agoric/agoric-sdk/blob/f5be67f6e5c0d5a01aca66256502e2c453e128ae/package.json#L85
It isn’t referenced from any other rule, and I didn’t invoke it. The wallet-connection is the last item mentioned in “workspaces” and it seemed to succeed, so the overall yarn lint should have succeeded.
Issue Analytics
- State:
- Created 2 years ago
- Comments:5 (5 by maintainers)
Top Results From Across the Web
Using yarn lint will fail with error ' was unexpected at this time ...
moved from exercism/exercism#3572 Typescript excecism using Windows OS (8.1) When running yarn lint above error will occur. error details: ...
Read more >yarn lint fails in turborepo - node.js - Stack Overflow
If I run yarn lint from the project level it throws this error api:lint: $ lb-eslint --report-unused-disable-directives . api:lint: ...
Read more >Enforcing Consistent Code in Expo React Native Projects
The problem is that ESLint doesn't consider "warnings" as fatal errors; so, yarn lint runs and quits with an exit code of 0....
Read more >How To Todo In Ember Template Lint
Next, run the command yarn lint:hbs again: a terminal showing 2 errors, 0 warnings, and 0 todos. Note: ember-template-lint also takes a ...
Read more >Avoid Lint Errors in CI with Git Hooks - Atomic Spin
It's a common practice to run linter tools in Continuous Integration. Git Hooks can help automate this process and stop lint errors from ......
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found

@turadg looks like prettier is not excluding
code_coverage. I think we really need a.prettierignorefile.Probably because @erights at some point ran coverage locally, and since it’s in
.gitignoreit’s laying around unnoticed. I regularly deep clean my local repo, so never run into such issues. CI doesn’t either because those tests likely use different runners.That said +1 for
.prettierignorebeing a superset of.gitignore