Convert and validate tsconfig compiler options

[mvdam]

This PR introduces conversion of the tsconfig.json file to a format that the TypeScript API accepts. It will also validate the config file and throws errors that were found in it.

With this compilation step, the option noEmitOnError will now work correctly and will show compilation errors in the emulator as well.

I hope this will be a nice addition! Please review and let me know if you have some feedback!

[simonhoss]

Awesome that you figured this out. I will check today evening if it works for me!

[simonhoss]

I tried it a bit sooner 😆

I get now an error which doesn't appear for yarn tsc -p tsconfig.json

error: bundling failed: Error: /Users/***/src/app.tsx (10,8): Module '"/Users/***/node_modules/@types/redux-promise/index"' has no default export.

Can you maybe share your tsconfig.json file?

[mvdam]

Looks like you need some kind of exclude? This is the config that I've tested with;

{
  "compilerOptions": {
    "target": "es5",
    "module": "es2015",
    "sourceMap": true,
    "experimentalDecorators": true,
    "jsx": "react-native",
    "lib": ["dom", "es2015", "es2016"],
    "allowSyntheticDefaultImports": true,
    "forceConsistentCasingInFileNames": true,
    "moduleResolution": "node",
    "noEmitHelpers": true,
    "importHelpers": true,
    "strict": true,
    "noImplicitReturns": true,
    "noImplicitThis": true,
    "noImplicitAny": true,
    "noEmitOnError": true,
    "strictNullChecks": true,
    "strictFunctionTypes": true,
    "strictPropertyInitialization": true,
    "noUnusedLocals": true,
    "skipLibCheck": true
  }
}

[simonhoss]

Ok. The problem with "has no default export." is solvable with allowSyntheticDefaultImports. Another problem which I have is that it doesn't support local @types.

I tried the config "typeRoots": ["./node_modules/@types", "./src/@types"],

Because of this I getting an error with a library which has no types and where I added manually the types

[mvdam]

Thanks for testing! I will try this as well and work on a fix somewhere in the coming days.

[mvdam]

Just did some testing and I was able to 'solve' it by setting "noImplicitAny": false in the tsconfig.json. But that shouldn't be the real solution. It really looks like we need to do things with the createProgram API to get this working. I will keep you posted when I've found out more!

[mvdam]

Okay, I have a fix but it's not great (WIP);

if (compilerOptions.noEmitOnError) {
      const glob = require('glob');
      const typings = glob.sync('./**/*.d.ts')

      const program = ts.createProgram(typings.concat(filename), compilerOptions)

Basically it grabs all the definitions and adds them to every program. This doesn't make things very fast. Also you need to restart the packager after each TS error. If you can think of any solutions for this let me know. Will try some other options as well.

[simonhoss]

Interesting, but I guess it should use the typeRoots config instead of adding all definition files

[mvdam]

I just pushed some changes that allows you to define typeRoots in the tsconfig.json. It seems to work fine now.

There is still one issue that has something to do with some caching. When there is a TS error (you get the red screen) and you resolve the error in your code, the packager sees the change but the error will not go away. You need to restart the RN packager to get rid of the error. But this problem is not caused by my changes tho. Do you have any idea how to solve that?

[fantasy525]

I just pushed some changes that allows you to define typeRoots in the tsconfig.json. It seems to work fine now.

There is still one issue that has something to do with some caching. When there is a TS error (you get the red screen) and you resolve the error in your code, the packager sees the change but the error will not go away. You need to restart the RN packager to get rid of the error. But this problem is not caused by my changes tho. Do you have any idea how to solve that?

come on guys!II need this feature,I'll keep an eye on your progress

[mvdam]

@fantasy525 It would be really cool if you can test this in your project. Is that something you could do?

[fantasy525]

@fantasy525 It would be really cool if you can test this in your project. Is that something you could do?

sure,but I don't know how to use noEmitOnError, just set "noEmitOnError": true?

[mvdam]

@fantasy525 It would be really cool if you can test this in your project. Is that something you could do?

sure,but I don't know how to use noEmitOnError, just set "noEmitOnError": true?

Yes; normally it would just continue on 'any' type of TypeScript error. With noEmitOnError it stops the compilation and inform you about the problem without outputting the compilation result.

[fantasy525]

@fantasy525 It would be really cool if you can test this in your project. Is that something you could do?

sure,but I don't know how to use noEmitOnError, just set "noEmitOnError": true?

Yes; normally it would just continue on 'any' type of TypeScript error. With noEmitOnError it stops the compilation and inform you about the problem without outputting the compilation result.

hello,I try it,but it does not work,

import React from 'react'
import { Component } from 'react';
import {Platform, StyleSheet, Text, View} from 'react-native';
type Props={}
export default class Hello extends Component<Props> {
  getText(name:string){
    return name;
  }
 render(){
   return (
     <View>
       <Text>{this.getText(33)}</Text>// i set number type
     </View>
   )
 }
} 

but rn still shows me 33 ....
my tsconfig.json

{
  "compilerOptions": {
   "target": "esnext",
    "lib": ["es6" ],
    "jsx": "react-native",
    "removeComments": true,
    "noEmit": false,
    "importHelpers": true,
    "noEmitOnError": true,
    "moduleResolution": "node",
    "allowSyntheticDefaultImports": true
 },
  "exclude": [
    "node_modules",
    "android",
    "ios"
  ]
}

[simonhoss]

Hi

Im sorry that I didnt merge this until now, I dont had time to test it.

@fantasy525 When it works for you I would merge it...

Greets

[mvdam]

@fantasy525 Unfortunately I don't have time for the coming two weeks to work on this. But after that I will look into it! Thanks for testing and sharing your code 👍 .

[mvdam]

Due to a lack of time to work on this and now that Babel is able to transform TypeScript I'm going to close this PR. I also believe that newer versions of Expo are no longer depending on this transformer anymore.