You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This issue has been created by the team responsible for the infrastructure behind most of Bloomberg's TypeScript code.
Summary
We have tested TypeScript 4.6.0-beta on our codebase and our experimentation has not revealed any new errors in TypeScript source, pointing to this being a straightforward update.
Grammar Errors in JavaScript Files
As reported in the 4.6 iteration plan, TypeScript now reports grammar errors for JavaScript files contained within TypeScript projects: #45349
These errors are now reported even when checkJs is not specified, and require explicit checkJs: false to disable them:
Before:
checkJsfalse or <unspecified>: no diagnostics on *.js files
checkJstrue: grammar + inference-based type errors on *.js files
After:
checkJsfalse: no diagnostics on *.js files
checkJs <unspecified>: grammar errors on *.js files
checkJstrue: grammar + inference-based type errors on *.js files
Is it intentional that users now need to be explicit to avoid any errors on *.js files?
Is it intentional that users now need to be explicit to avoid any errors on *.js files?
Yes. It's worth pointing out that previous versions of the compiler issued syntax errors from the parser on JS files, with no way to turn them off. That behaviour hasn't changed. The grammar errors that now appear with checkJs unspecified are supposed to be a similar class of syntax error, but too complex to issue from the parser.
Interesting. Can you share what kind of grammar errors were encountered?
Virtually all of the grammar errors that are now reported are redeclaration errors. They are technically valid errors for our JavaScript source, and we're actively working on fixing them. However, without going into too much detail, they don't cause runtime errors for our specific runtime. As such our solution is to set checkJs: false for these projects, ignoring these grammar errors. This allows us to maintain the same set of diagnostics from ts4.5 (for now) while re-evaluating our strategy for how we'll tackle these.
Can you describe the structure of the files that contain the redeclaration errors? Are they scripts (files without import/export)? Are they compiled all at once, but loaded or bundled individually?
Michael Molisani (@molisani) It would help me to talk to you to decide whether Bloomberg's errors will appear in most other codebases and whether to turn off that error. I sent you a DM on twitter in case you have time in the next couple of days.
From talking in person, it sounds like the mismatch between the new errors and the runtime should only apply to Bloomberg, and the few other people who are using that (quite old) runtime.
Activity
RyanCavanaugh commentedon Feb 9, 2022
Interesting. Can you share what kind of grammar errors were encountered?
sandersn commentedon Feb 9, 2022
Yes. It's worth pointing out that previous versions of the compiler issued syntax errors from the parser on JS files, with no way to turn them off. That behaviour hasn't changed. The grammar errors that now appear with checkJs unspecified are supposed to be a similar class of syntax error, but too complex to issue from the parser.
molisani commentedon Feb 9, 2022
Virtually all of the grammar errors that are now reported are redeclaration errors. They are technically valid errors for our JavaScript source, and we're actively working on fixing them. However, without going into too much detail, they don't cause runtime errors for our specific runtime. As such our solution is to set
checkJs: falsefor these projects, ignoring these grammar errors. This allows us to maintain the same set of diagnostics from ts4.5 (for now) while re-evaluating our strategy for how we'll tackle these.sandersn commentedon Feb 9, 2022
Can you describe the structure of the files that contain the redeclaration errors? Are they scripts (files without import/export)? Are they compiled all at once, but loaded or bundled individually?
sandersn commentedon Feb 9, 2022
Michael Molisani (@molisani) It would help me to talk to you to decide whether Bloomberg's errors will appear in most other codebases and whether to turn off that error. I sent you a DM on twitter in case you have time in the next couple of days.
sandersn commentedon Feb 9, 2022
From talking in person, it sounds like the mismatch between the new errors and the runtime should only apply to Bloomberg, and the few other people who are using that (quite old) runtime.