allowSyntheticDefaultImports flag in tsconfig.json

[YagoLopez]

In "Importing a Component" section in https://github.com/wmonk/create-react-app-typescript/blob/master/packages/react-scripts/template/README.md it says:

This project setup supports ES6 modules thanks to Babel.
While you can still use require() and module.exports, we encourage you to use import and export instead.

For example:

Button.js

import React, { Component } from 'react';

class Button extends Component {
  render() {
    // ...
  }
}

export default Button; // Don’t forget to use export default!

I had problems with this and had to use:

import * as React from 'react';

export default class Button extends React.Component {
//...
}

After some investigation I could use the first way using the flag allowSyntheticDefaultImports: true in tsconfig.json. I thought it could be useful for others to know it. Is it worth to make a pull request to add this to the README.md file?

[DorianGrey]

Hm... that readme section definitely need some additions.
However, that section should mention that import * as React from 'react'; is required with the typescript version to make things work correctly.
The version mentioned in the current readme only works when using babel in the toolchain, since it adds the required default field to react's export (which uses commonjs format) due to some "compatibility" adjustments regarding ES2015 modules. allowSyntheticDefaultImports: true only allows to make the typescript compiler assume the presence of the default export, but it won't be added in case it's absent.

[YagoLopez]

Aha, so the way you import modules depends on the create-react-app-ts version, is that correct?
If that's true it should be mentioned in the readme as you say.

[DorianGrey]

Simplified, it's about create-react-app vs create-react-app-ts. The "original" version uses babel by default, while the latter doesn't. babel takes care of adding the default field to exports in commonjs format. The typescript docs explictly mention that allowSyntheticDefaultImports is only true by default when using the system module format, since for every other case, another transpiler or the module bundler has to take care of adding that kind of "compatibility" layer.

[YagoLopez]

I see, It's a complicated question. Thanks for taking the time to answer. Anyway in my personal opinion due to the fact that by default Typescript (if I'm not wrong) comes with allowSyntheticDefaultImports = false could be useful to mention it in the docs.

[Hotell]

also note that with allowSyntheticDefaultImports:true test won't work if you'll use dynamic import() :(

• that might be issue with ts-jest...
• question: is there any way to enable babel to compile ? ( babel has import-dynamic-plugin, which handles this in original create-react-app )

with allowSyntheticDefaultImports:false, import() works...

[YagoLopez]

@Hotell interesting corner case. Does your code compile with dynamics imports and allowSyntheticDefaultImports: true and fails with jest tests?

Also I dont know the details of your case but if you want to use babel a quick idea is to use CRA instead of CRA-typescript. Not sure if this has sense in your case.

[Hotell]

Does your code compile with dynamics imports and allowSyntheticDefaultImports: true and fails with jest tests?

yup, so we had to switch to System.import so both tests and app works :(

Also I dont know the details of your case but if you want to use babel a quick idea is to use CRA instead of CRA-typescript. Not sure if this has sense in your case.

Doesn't make much sense...would do double physical compilation ( running tsc -w + webpack-dev-server )

[mlwilkerson]

I just hit a similar situation where the normal build with yarn start or yarn build worked fine, but yarn test failed due to the allegedly missing default export. Adding the allowSyntheticDefaultImports: true to tsconfig.test.json got it working.

[YagoLopez]

@mlwilkerson good to know it... Also other question, maybe it should be a new issue, but in my case I had to install react-test-renderer to run snapshot tests with jest. Perhaps that should be mentioned in the test section in the docs.

[Hotell]

@mlwilkerson

Adding the allowSyntheticDefaultImports: true to tsconfig.test.json got it working.

That doesn't make any sense, as {allowSyntheticDefaultImports: true} is defined within tsconfig.json which is extended by tsconfig.test.json so it's already set to true => so it doesn't work

@YagoLopez

but in my case I had to install react-test-renderer to run snapshot tests with jest

That's in the documentation so it's not an issue rather documented fact

[YagoLopez]

@mlwilkerson react-test-renderer is only mentioned when using Enzyme. For Jest+snapshot there isn't any mention to react-test-renderer as dependency.

https://github.com/wmonk/create-react-app-typescript/blob/master/packages/react-scripts/template/README.md#running-tests

Anyway it is a subjective matter. I guess I like this point of view: https://en.wikipedia.org/wiki/Don%27t_Make_Me_Think
😄

[mlwilkerson]

@Hotell my tsconfig.json does not have {allowSyntheticDefaultImports: true}, and the default is false, so setting it to true in tsconfig.test.json does change the behavior.

[DorianGrey]

@mlwilkerson ,
@Hotell
I'll see if I can shed some light on this ...

As you already might have figured out from reading the ts-jest docs, it supports post-processing code via babel. This mode is selected automatically in case of allowSyntheticDefaultImports: true, as long as this selection is not explicitly suppressed via a skipBabel flag (see here).
The post-process hook is created here: https://github.com/kulshekhar/ts-jest/blob/36875a405db1aea846615f09bc6bda5efb3ce214/src/postprocess.ts#L59
It results in a transformer as required by jest, see: https://github.com/kulshekhar/ts-jest/blob/36875a405db1aea846615f09bc6bda5efb3ce214/src/postprocess.ts#L18

Using a custom .babelrc is possible. Alternatively, a babelConfig property with the explicit config can be provided. By default, ts-jest only takes care that the module kind is properly translated to commonjs, since the tests have to be executable on node. That's a difference to the start or build command, where the module bundler (here: webpack) takes care of handling static and dynamic imports.

To support one of the flags mentioned above, it would be required to change the jest config generated here. However, at least for the .babelrc, I'm not sure where it attempts to pick it up from or at least searches for it. Would be worth trying to add this flag and see if a .babelrc provided in the root of a generated project would be picked up properly. You might do that locally by modifying the package sources in a generated project. However, using this value by default might cause problems for users that don't want to use babel at all, or are fine with the default settings.

@mlwilkerson , regarding the project you mentioned: I suppose the change listed was required since you used import FontAwesomeIcon from '@fortawesome/react-fontawesome'; for importing from commonjs format without explicitly providing a default export (at least it looks like that in projects index file at that branch), i.e. something like module.exports.default=module.exports (similar to what babel's interop does). In general, allowSyntheticDefaultImports: true only suppresses warnings about the type definitions that do not include a default export, but that doesn't have any effect on the generated output - the ts-jest behavior to use babel as postprocessor in that case is exceptional here.

In general, I would not recommend to test code that includes dynamic import statements with jest - these are intended to be processed by bundlers (or the browser), and not on node.

[YagoLopez]

To test code with dynamic imports seems problematic indeed. An option could be try to mock dynamicaly loaded code.