Lint rule for unminified errors #15757
Conversation
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.
|
No significant bundle size changes to report. Generated by 🚫 dangerJS |
| 'map, so it can be stripped from the production builds. ' + | ||
| "Alternatively, if you're updating an existing error " + | ||
| 'message, you can modify ' + | ||
| '`scripts/error-codes/codes.json` directly.' |
There was a problem hiding this comment.
Seems like it would be nice to log the error message too.
There was a problem hiding this comment.
I figured this was fine because if you have ESLint in your editor, it will display the lint error inline with the message.
The RN modules don't use error extraction so those errors don't get added to the error map. Alternatively, I could add those errors to the error map even though they aren't used. |
|
As a failsafe, #15758 includes a post-build check for unminified messages, just in case someone suppresses a lint error than they shouldn't have. |
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.