jsconfig default settings for module type is inconsistent

[egamma]

No jsconfig.json in the workspace
Then the module type defaults to none

jsconfig.json exists but no module property defined
Then the module type defaults to commonjs

Suggest that the module type default is always the same independent of whether there is a jsconfig.json.

If the module property is commonjs by default then I suggest that there is also a default for exclude containing the node_modules folder.

[mhegazy]

the problem here was you will get an error:

error TS1148: Cannot compile modules unless the '--module' flag is provided. Consider setting the 'module' compiler option in a 'tsconfig.json' file.

which most ppl have found annoying int he past. given that JS users would probably have a transpiler already, do we want to show them that error?

[zhengbli]

@mhegazy Does't the default module option also impact how we resolve modules for js files? Even without the error message

[egamma]

@mhegazy the error message is unpleasant since I don't think of code generation when I use JS only. However, given your argument, shouldn't then the default also be commonjs when there is no jsconfig.json?

[mhegazy]

that is correct, but for that we could set the "moduleResolution" flag, but the error still stays.

[mhegazy]

shouldn't then the default also be commonjs when there is no jsconfig.json?

in retrospect, yes :) but this would be a big breaking change.

[billti]

I sent an email on this couple mins ago... repeating below

We chose the current behavior as without a ‘module’ setting the TypeScript engine gives you errors on import/export statements that no module type is defined. With an ES3/ES5 emit target (the default and most common settings), we need to know how to treat these (e.g. as CommonJS, AMD, or System modules). With JavaScript also (optionally) being transpiled now, the same problem exists.

We initially did have a default other than ‘none’, but found too many users were trying to use modules without understand them and the need for a runtime that supported them, so we wanted to add a little impedance to make them stop and think “what module type are trying to use”, and maybe look at some docs if not sure.

Some of the user confusion was caused by TypeScript overloading the “module” keyword for both internal & external modules. Now we’ve moved to “namespace” for internal modules, this should be lessened. Also, Node development being more prevelant, and with CommonJS also being commonly the format of choice in the browser (via browserify, WebPack, etc.), perhaps we could consider defaulting to CommonJS again. Thus ES6 import/export syntax just works, and would emit CommonJS by default, if there is no “module” setting provided.

[mhegazy]

in retrospect, yes :) but this would be a big breaking change.

correction for my original statement, that would not be a breaking change, existing projects should not be affected. it would be a surprising change though to existing users of TS.

We should consider this for the design meeting tomorrow.

[mhegazy]

Conclusion is to move to CommonJs as the default module kind

[egamma]

a good outcome, thanks.

Should this also be assigned to the Salsa 0.9 milestone?

[mhegazy]

closing in favor of #6807