Usage with esModuleInterop option

[mihkeleidast]

Hi, thanks for this docgen!

TypeScript 2.7 added the --esModuleInterop compiler option. This should simplify imports, for example if previously it was necessary to import * as React from 'react';, it is now possible to import React from 'react'; and the TypeScript compiler is happy.

However, by using the new import statements, react-docgen-typescript stopped working. It does not recognize the parsed file as a React component anymore (i think). '

Any idea how I could get this to work?

[pvasek]

Do you use it with your custom tsconfig.json file?

propsParser: require('react-docgen-typescript').withCustomConfig('./tsconfig.json', [parserOptions]).parse

[strothj]

Hello,

I had an issue come up regarding this in my project (which is a wrapper for this one):
strothj/react-docgen-typescript-loader#10

It seems that:

import React from "react";

const MyComponent: React.SFC ...

doesn't work, while this does:

import React, { SFC } from "react";

const MyComponent: SFC ...

[mihkeleidast]

@pvasek no, I got into all sorts of trouble when trying to use my custom tsconfig.json. I'm using react-docgen-typescript in a separate shared project (a Fractal theme, so not using styleguidist) from my styleguide projects, so referencing the tsconfig is not as simple.

But I tried changing the defaultOptions in my node_modules folder to see if it would work - it did not.

[amacleay]

@Risker - I am guessing you have target as ES5 (as does @strothj in his loader [thanks for that loader, I'm using it and it's great!])

I had the same problem (but I'm an idiot and opened a separate issue for it: #102). The fix for me was to change the target to ES6. (If, in addition, it's necessary that the output of tsc be runnable node code, I needed to add "module": "CommonJS")

We figured this out after @photusenigma pointed me at this issue.

My working config for a TS storybook project looks like the following (since it is babel-ified in storybook, there is no need for "module": "CommonJS"):

{
  "compilerOptions": {
    /* Basic Options */
    "target": "es2015",
    "lib": [ // Specify library files to be included in the compilation.
      "dom",
      "es2015",
      "es2017"
    ],
    "jsx": "react", // Specify JSX code generation.

    /* Strict Type-Checking Options: you may not need this but we are pedants */
    "strict": true, // Enable all strict type-checking options.
    "strictNullChecks": true, // Enable strict null checks.

    /* Additional Checks */
    "noUnusedLocals": true, // Report errors on unused locals.
    "noUnusedParameters": true, // Report errors on unused parameters.
    "noImplicitReturns": true, // Report error when not all code paths in function return a value.
    "noFallthroughCasesInSwitch": true, // Report errors for fallthrough cases in switch statement.

    /* Module Resolution Options */
    "moduleResolution": "node", // Specify module resolution strategy.
    "allowSyntheticDefaultImports": true, // Allow default imports from modules with no default export. This does not affect code emit, just typechecking.
    "esModuleInterop": true, // Enables emit interoperability between CommonJS and ES Modules via creation of namespace objects for all imports.
  },
  "exclude": ["node_modules/"]
}

[mihkeleidast]

Hey, I just found a small error on my part - I had npm linked two projects and one of them had an old TypeScript version, which is why changing the defaultOptions did not work before. I updated the TypeScript version and now it works when I change the default options.

So I would like to change the objective of this issue - could it be possible to add esModuleInterop: true to the defaultOptions? It should not break anything already working.

[hipstersmoothie]

esModuleInterop can make build time significantly slower and should not be part of the default. This should all work if you use your tsconfigs parser options. @pvasek I think this one is safe to close