TypeScript support unnecessarily forces "esnext" code generation [canary]

Bug report

Describe the bug

Next.js currently forces that the tsconfig.json file in the source directory has a "module" configuration value of "esnext". This causes any uses of TypeScript that share that tsconfig to generate code that uses import and export statements, which are not supported by all tools (such as Node 8).

From my understanding of the module configuration setting, it only affects TypeScript’s code generation, which Next does not use (it even forces noEmit). Rather, Next’s webpack configuration uses TypeScript for typechecking only and Babel for actual code generation.

Therefore, the value of module should be irrelevant to Next.js.

Expected behavior

Next.js should have no opinion about what the module setting is.

System information

• Version of Next.js: 8.1.1-canary.29

Additional context

This is hitting me in a scenario where my Next app shares a root with some scripts written in TypeScript that I run with ts-node. Because my team’s environment is Node 8, it errors when it sees the code that was generated to have ES6 modules.

I think the same logic applies to the isolatedModules setting, which also seems to only affect TypeScript’s code generation. I’ve had to add import {} statements in my server code that feel unnecessary.

[fionawhim]

Yep, those are all useful workarounds. But I would be happier if Next.js didn’t require any TypeScript settings it didn’t need, and even if it did need them (like --noEmit) see if they could be moved to Next’s invocation of tsc rather than forcing them into the tsconfig.json file itself.

[fionawhim]

@Timer OK. I think we can implement workarounds.

Regardless, thanks for adding in native TypeScript support! This is a huge win for Next and I’m glad that our webapps will be able to adopt it.