Conversation
**Why**: To be able to support the use of React i18n functions outside the document-capture package (e.g. in the components package), and to better separate shared utilities and simplify the scope of the document-capture package.
**Why**: Avoid tedium of adding exceptions for all test strings
**why**: Some spec files may contain lingering references to unused or missing strings, which we'd want to be made aware of. The ones we don't care about are pretty isolated to these packages
tsconfig.json
Outdated
| "target": "ESNext" | ||
| }, | ||
| "include": [ | ||
| "spec/javascripts/spec_helper.d.ts", |
There was a problem hiding this comment.
Ideally it'd be nice to limit this to be included only in the context of spec files, since it occurs to me that this would allow someone to add expect calls to application code without it being flagged.
We can do this with ESLint configuration to at least make expect be considered undefined by moving globals into the overrides section for spec files, which seems like a reasonable compromise.
There was a problem hiding this comment.
Ideally it'd be nice to limit this to be included only in the context of spec files, since it occurs to me that this would allow someone to add
expectcalls to application code without it being flagged.We can do this with ESLint configuration to at least make
expectbe considered undefined by movingglobalsinto theoverridessection for spec files, which seems like a reasonable compromise.
Updated in 51e6a7e.
**Why**: So that a developer who tries to use expect in application code will encounter a failed build
2 participants
Follows-up #5459
Why: To be able to support the use of React i18n functions outside the document-capture package (e.g. in the components package), and to better separate shared utilities and simplify the scope of the document-capture package.
It's planned to use this for LG-5213, where the
BlockLinkcomponent will be moved to the components package, and requires translation.