Skip to content
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

Fail compilation less aggressively in test watch #681

Closed
chrbala opened this issue Apr 13, 2020 · 3 comments
Closed

Fail compilation less aggressively in test watch #681

chrbala opened this issue Apr 13, 2020 · 3 comments
Labels
kind: support Asking for support with something or a specific use case problem: stale Issue has not been responded to in some time solution: already possible This is already possible / this feature already exists solution: workaround available There is a workaround available for this issue

Comments

@chrbala
Copy link

chrbala commented Apr 13, 2020

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.

@agilgur5
Copy link
Collaborator

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 agilgur5 added the kind: support Asking for support with something or a specific use case label Apr 13, 2020
@agilgur5 agilgur5 added problem: stale Issue has not been responded to in some time solution: workaround available There is a workaround available for this issue labels Oct 22, 2020
@agilgur5 agilgur5 added the solution: already possible This is already possible / this feature already exists label Nov 14, 2020
@adi518
Copy link

adi518 commented Dec 28, 2020

@agilgur5 Configuring tsconfig.test.json doesn't work. It gets ignored. I think it's a bug in TSDX, but I could be wrong.

@agilgur5
Copy link
Collaborator

agilgur5 commented Apr 17, 2022

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind: support Asking for support with something or a specific use case problem: stale Issue has not been responded to in some time solution: already possible This is already possible / this feature already exists solution: workaround available There is a workaround available for this issue
Projects
None yet
Development

No branches or pull requests

3 participants