-
Notifications
You must be signed in to change notification settings - Fork 1.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fill out the TS Config reference #121
Conversation
Got false positives?Make changes to the global settings spellcheck.json in /artsy/peril-settings. Typos for useDefineForClassFields.md
Typos for typeRoots.md
Typos for typeAcquisition.md
Typos for target.md
Typos for stripInternal.md
Typos for strict.md
Typos for sourceMap.md
Typos for resolveJsonModule.md
Typos for removeComments.md
Typos for pretty.md
Typos for preserveSymlinks.md
Typos for preserveConstEnums.md
Typos for plugins.md
Typos for outDir.md
Typos for out.md
Typos for noImplicitUseStrict.md
Typos for noFallthroughCasesInSwitch.md
Typos for noEmitHelpers.md
Typos for noEmit.md
Typos for moduleResolution.md
Typos for mapRoot.md
Typos for lib.md
Typos for keyofStringsOnly.md
Typos for isolatedModules.md
Typos for inlineSourceMap.md
Typos for incremental.md
Typos for importHelpers.md
Typos for generateCpuProfile.md
Typos for files.md
Typos for extends.md
Typos for esModuleInterop.md
Typos for downlevelIteration.md
Typos for disableSourceOfProjectReferenceRedirect.md
Typos for declarationDir.md
Typos for declaration.md
Typos for charset.md
Typos for alwaysStrict.md
Typos for allowUmdGlobalAccess.md
Typos for allowSyntheticDefaultImports.md
Typos for README.md
Typos for README.md
Lighthouse Scores
|
Performance | Accessibility | Best Practices | SEO | Progressive Web App |
---|---|---|---|---|
0.91 | 1 | 0.93 | 0.89 | 0.96 |
/tsconfig
Performance | Accessibility | Best Practices | SEO | Progressive Web App |
---|---|---|---|---|
0.92 | 0.99 | 1 | 0.91 | 0.96 |
/docs/handbook/integrating-with-build-tools.html
Performance | Accessibility | Best Practices | SEO | Progressive Web App |
---|---|---|---|---|
0.96 | 1 | 1 | 0.89 | 0.96 |
Snapshots updated
backstop_default_TSConfig_Example_0_viewport_0_phone.png
Before | After |
---|---|
backstop_default_TSConfig_Example_0_viewport_1_tablet.png
Before | After |
---|---|
backstop_default_TSConfig_Example_0_viewport_2_computer.png
Before | After |
---|---|
…into tsconfig-docs-merge
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
All should be taken as cosmetic comments.
const isError = errors.find(e => { | ||
return e.character <= pos && e.character + e.length >= pos + token.content.length | ||
}) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(That's a step in the opposite direction from what I'd do :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You're not wrong, but it became much easier to debug this way
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@orta, so now I'm curious -- how did it become easier?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It made it easier to switch the function to log like this:
const findTokenDebug = start => e => {
const result = start <= e.character && start + token.content.length <= e.character + e.length
console.log(result, start, '<=', e.character, '&&', start + token.content.length, '<=', e.character + e.length)
return result
}
and jump back and forth, in the current version I'm working on I just have a separate debug logging function instead
} | ||
``` | ||
|
||
This `tsconfig.json` file will *only* include `./node_modules/@types/node`, `./node_modules/@types/lodash` and `./node_modules/@types/express`. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe:
node
,lodash
, andexpress
in the./node_modules/@types
directory.
instead?
(Also, double space after "include".)
``` | ||
|
||
This `tsconfig.json` file will *only* include `./node_modules/@types/node`, `./node_modules/@types/lodash` and `./node_modules/@types/express`. | ||
Other packages under `node_modules/@types/*` will not be included. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe compare to the previous option?
--- | ||
|
||
This flag is used as a part of migrating to the upcoming standard version of how class fields works. TypeScript introduced class fields many years before it was ratified in TC39, where it had a different runtime behavior but the same syntax. This flag switches to the ECMA runtime behavior. | ||
This flag is used as a part of migrating to the upcoming standard version of how class fields works. TypeScript introduced class fields many years before it was ratified in TC39. The latest version of the upcoming specification has a different runtime behavior to TypeScript's implementation but the same syntax. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"... used as a part of ..."
"standard version of how class fields works."
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
All should be taken as cosmetic comments.
Alright, I'm going to merge this and to get the ball rolling - I will still take feedback in here and just merge it into v2 |
Separating this PR to only be (more or less) only text content for the reference so that it can be easier for the team to read and review once there's docs for every compiler flag.
General gist:
I'm still not sold on whether the editor should live on the side, or a sidebar of all items.
PR Preview: https://typescript-v2-121.ortam.now.sh/tsconfig