Closed chrbala closed 4 years ago
You can already configure this in your jest.config.js
. TSDX just uses ts-jest
under-the-hood.
You can turn off ts-jest
's diagnostics with:
jest.config.js
:
module.exports = {
// [...]
globals: {
'ts-jest': {
diagnostics: false
}
}
};
Can also configure a tsconfig.test.json
for reporting less errors.
A discussion about whether to turn this off as a default is in #521 .
@agilgur5 Configuring tsconfig.test.json
doesn't work. It gets ignored. I think it's a bug in TSDX, but I could be wrong.
Configuring
tsconfig.test.json
doesn't work. It gets ignored.
It doesn't work out-of-the-box, you need to configure ts-jest
to use tsconfig.test.json
:
jest.config.js
:
module.exports = {
// [...]
globals: {
'ts-jest': {
tsConfig: 'tsconfig.test.json'
}
}
};
I think it's a bug in TSDX, but I could be wrong.
Not a bug, it's not a feature of TSDX to read that out-of-the-box, it requires configuration of ts-jest
as per above. That was just an example I gave of something that could be configured alternatively.
Current Behavior
If you're iterating on some code with a tests watch mode, the build will fail if there are issues like unused imports, unused variables, etc.
Desired Behavior
A way to ignore typescript errors in test watching mode
Suggested Solution
Add the
--transpileOnly
flag to test mode, which would disable the type checking and other TS enforced rules to tests in any mode.Who does this impact? Who is this for?
There should be an option to make the test watch command more forgiving. It's a drag on productivity to have to comment out code that works but is just not used.
I can even see value in not failing builds/tests at all even for type errors. I personally at least have gotten used to a workflow of starting with making interfaces work correctly, then make sure the types work correctly internally. The compiler constantly failing slows me down, even though I will eventually will be creating and relying on correct types.
Describe alternatives you've considered
Automatically apply this in all test modes. This might be good too, depending on the team's designs.
Additional context
I'm coming from using Flow, where for the most part type checking was a separate process in the terminal and the types were only stripped from the source in the build process. The build would never fail due to the types, and I got pretty used to workflows based on this.