Repository navigation
jsconfig default settings for module type is inconsistent #6690
Description
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.
Activity
mhegazy commentedon Jan 28, 2016
the problem here was you will get an error:
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 commentedon Jan 28, 2016
Mohamed Hegazy (@mhegazy) Does't the default module option also impact how we resolve modules for js files? Even without the error message
egamma commentedon Jan 28, 2016
Mohamed Hegazy (@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 commentedon Jan 28, 2016
that is correct, but for that we could set the "moduleResolution" flag, but the error still stays.
mhegazy commentedon Jan 28, 2016
in retrospect, yes :) but this would be a big breaking change.
billti commentedon Jan 28, 2016
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 commentedon Jan 28, 2016
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 commentedon Jan 29, 2016
Conclusion is to move to CommonJs as the default module kind
egamma commentedon Feb 1, 2016
a good outcome, thanks.
Should this also be assigned to the Salsa 0.9 milestone?
mhegazy commentedon Feb 2, 2016
closing in favor of #6807