112168f31b
* Lint rule for unminified errors Add a lint rule that fails if an invariant message is not part of the error code map. The goal is to be more disciplined about adding and modifiying production error codes. Error codes should be consistent across releases even if their wording changes, for continuity in logs. Currently, error codes are added to the error code map via an automated script that runs right before release. The problem with this approach is that if someone modifies an error message in the source, but neglects to modify the corresponding message in the error code map, then the message will be assigned a new error code, instead of reusing the existing one. Because the error extraction script only runs before a release, people rarely modify the error code map in practice. By moving the extraction step to the PR stage, it forces the author to consider whether the message should be assigned a new error code. It also allows the reviewer to review the changes. The trade off is that it requires more effort and context to land new error messages, or to modify existing ones, particular for new contributors who are not familiar with our processes. Since we already expect users to lint their code, I would argue the additional burden is marginal. Even if they forget to run the lint command locally, they will get quick feedback from the CI lint job, which typically finishes within 2-3 minutes. * Add unreleased error messages to map |
||
|---|---|---|
| .. | ||
| babel | ||
| bench | ||
| circleci | ||
| error-codes | ||
| eslint | ||
| eslint-rules | ||
| flow | ||
| git | ||
| jest | ||
| perf-counters | ||
| prettier | ||
| print-warnings | ||
| release | ||
| rollup | ||
| shared | ||
| tasks | ||
| authors | ||