Skip to content

Convert and validate tsconfig compiler options #1

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

Closed
wants to merge 2 commits into from

Conversation

mvdam
Copy link

@mvdam mvdam commented Aug 8, 2018

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.

screen shot 2018-08-08 at 10 26 14

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

screen shot 2018-08-08 at 10 30 46

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

@simonhoss
Copy link
Owner

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

@simonhoss
Copy link
Owner

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
Copy link
Author

mvdam commented Aug 8, 2018

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
Copy link
Owner

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
Copy link
Author

mvdam commented Aug 9, 2018

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

@mvdam
Copy link
Author

mvdam commented Aug 17, 2018

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
Copy link
Author

mvdam commented Aug 17, 2018

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
Copy link
Owner

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

@mvdam
Copy link
Author

mvdam commented Sep 24, 2018

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
Copy link

fantasy525 commented Oct 2, 2018

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
Copy link
Author

mvdam commented Oct 2, 2018

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

@fantasy525
Copy link

@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
Copy link
Author

mvdam commented Oct 2, 2018

@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
Copy link

fantasy525 commented Oct 2, 2018

@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
Copy link
Owner

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
Copy link
Author

mvdam commented Oct 9, 2018

@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
Copy link
Author

mvdam commented Feb 15, 2019

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.

@mvdam mvdam closed this Feb 15, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants