ds300/react-native-typescript-transformer

Feature request: respect 'noEmitOnError'

almostintuitive opened this issue · 3 comments

almostintuitive commented

Hi,

It's super nice to see this happening!

noEmitOnError is the one of the main reasons we're using TypeScript.
It'd be great if the packager would fail the build if there's a type error - that's currently the expected way according to everyone who's working on this project.

We'd be happy to even submit a PR for this. Will/would it be accepted?

Thank you!

ds300 commented

This was already discussed in #15

I would very much like to be able to provide this as an option. If you can overcome the following problems I'd gladly accept a PR for the feature:

  • How to configure react-native-typescript-transformer to enable/disable this feature (I think it should be opt-in)
  • How to make sure that if you change file A and it creates a type error in file B which didn't change, that the error is reported properly.
almostintuitive commented

  • I think "noEmitOnError" would be a great option, that's already a valid compiler flag

  • This may be solved by the way this will be implemented anyway. AFAIK, we won't be able to use .transpileModule, since that method does not report type errors/warnings.
    So far, my conclusion is that because of the differences between the behaviour of tsc and transpileModule, we'll need to run tsc in some way, and then collect the compiled module, rather than calling methods on the public API. is this also your understanding?

For reference, there are quite a few issues on the TS repo documenting the difference between tsx and transpileModule
microsoft/TypeScript#4864

henrikra commented

I think the workaround for this problem which is here #15 (comment) should be mentioned in README etc because this prevents developer to commit shit to the code base :D

  • 👍4
  • 😕1