We recommend our contributors to use VisualStudio Code with the following extensions installed:
- Prettier - Code Formatter for automatic formatting of source files on save.
- ESLint to highlight and auto-fix linting problems directly in the editor.
Our monorepo comes with few preconfigured VSCode Tasks:
- The build task is configured to run the TypeScript compiler
- The test task is configured to run
npm test
(which runs the build before running any tests).
-
Open any existing TypeScript file, e.g.
packages/core/src/index.ts
-
Add a small bit of code to break TypeScript's type checks, for example:
const foo: number = 'bar';
-
Verify that VS Code editor has marked
foo
with a red underscore. Hover overfoo
and check the problem message. It should mention[ts]
source, e.g.[ts] Type '"bar"' is not assignable to type 'number'.
-
Check VS Code's PROBLEMS Window. There should be an entry showing the same eslint error. When you click on the entry, it should jump on the problematic line.
-
Close the editor tab. (This will clear the PROBLEMS entry reported by ESLint extension).
-
Run the test task ("Tasks: Run test task"). This will invoke package scripts like
npm test
under the hood. -
Open "Tasks" OUTPUT window and verify that compilation error was parsed by VSCode.
-
Verify that compilation errors are correctly associated with the problematic source code line.
Verify that "Go to definition" works across package boundaries. Find a place
where we are calling @inject
in authentication
package, press F12 to go to
the definition of inject
. VSCode should jump to the .ts
file in src
(as
opposed to jumping to a .d.ts
file in dist
)
Verify that refactorings like "rename symbol" (F2
) will change all places
using the renamed entity. Two different scenarios to verify: rename at the place
where the entity is defined, rename at the place where the entity is used. (You
can e.g. rename inject
to test.)
-
Open any existing TypeScript file, e.g.
packages/src/index.ts
-
Verify that ESLint extension is not reporting any warnings in the output window:
- pres Cmd+shift+P or Ctrl+shift+P to open task selector
- find and run the task
ESLint: Show Output
- check the logs
An example of a warning we want to avoid:
Warning: The 'no-unused-variable' rule requires type information.
-
Introduce two kinds linting problems - one that does and another that does not require type information to be detected. For example, you can add the following line at the end of the opened
index.ts
:const foo: any = 'bar';
-
Verify that VS Code editor has marked
any
with a red underscore. Hover overany
and check the problem message. It should mentionno-any
rule, e.g.[eslint] Type declaration of 'any' loses type-safety. Consider replacing it with a more precise type. (no-any)
-
Check VS Code's PROBLEMS Window. There should be an entry showing the same eslint error. When you click on the entry, it should jump on the problematic line.
-
Close the editor tab. (This will clear the PROBLEMS entry reported by ESLint extension).
-
Run the test task ("Tasks: Run test task"). This will invoke package scripts like
npm test
under the hood. -
Open "Tasks" OUTPUT window and verify that two eslint problems were reported:
ERROR: /Users/(...)/packages/core/src/index.ts[16, 7]: 'foo' is declared but its value is never read. ERROR: /Users/(...)/packages/core/src/index.ts[16, 12]: Type declaration of 'any' loses type-safety. Consider replacing it with a more precise type.
-
Open "PROBLEMS" window again. Verify that both problems were parsed by VS Code and are correctly associated with the problematic source code line.