You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Optional enforcement of explicit namespace imports #11712
Yesterday I was trying to import React into a file that would be transpiled and run on the browser, but kept getting errors about require not found. I think the problem is that the modules are being resolved in a way compatible with nodejs, but not for the browser. There are a dozen different module systems that can be targeted in tsconfig.json, and I find it really difficult to understand when I need a /// directive at the top of my file and when I don't. Sometimes it works to import {x] from x, other times it only works when you do x= require('x').
Ambiguities like this could be addressed with a rule to enforce stricter namespace import rules, preferably similar to those in C#.
Proposal
Provide a single consistent syntax for importing modules.
Add an optional compiler flag similar to noImplicityAny (which I think is awesome) which would enforce the following:
Every file must have a namespace.
Every module must be explicitly imported before use in that file, no exceptions.
Justifications:
If every file has a namespace, the rules of module resolution become much simpler and easier to understand.
Explicitly importing every module before use would prevent accidentally trying to use node api's on the browser, and vice-versa.
A single syntax for importing modules lets the user delegate the complex task of bundling dependencies to the compiler. This opens up a lot of possibilities for interesting and sophisticated build systems without overburdening the user.
to maintain backward compatibility for user code before TS 1.6. issue #11434 tracks changing the default.
And why doesn't commonjs support outFile?
This is not a simple concat procese like in sysmte/amd. commonjs has specific meaning for require/filenames. if you want a module blunder for commonjs, use browserify or wepback.
So my origional proposal is more or less already how things work, and what tripped me up was an unexpected set of defaults, which this suggestion would not address. I'll go ahead and close it up then.
Activity
mhegazy commentedon Oct 18, 2016
do not see why this is required.
this is true today. you can not use a module without importing it. see http://www.typescriptlang.org/docs/handbook/modules.html and http://www.typescriptlang.org/docs/handbook/namespaces-and-modules.html for more information.
aluanhaddad commentedon Oct 18, 2016
Benjamin Humpherys (@brhumphe) This sounds like a loader configuration issue. What is your setup?
brhumphe commentedon Oct 19, 2016
This is a repo with the minimal setup.
Targeting
commonjscompiles fine, but when I try to targetamd,system,umd,es6, ores2015,tscgives the errorCannot find the module 'react'.What is the mistake I am making here? And are there any compile-time checks or systems that would prevent it?
blakeembrey commentedon Oct 19, 2016
Benjamin Humpherys (@brhumphe) You need to set
moduleResolution: node. It's the default when usingcommonjs, but not the others. See https://www.typescriptlang.org/docs/handbook/compiler-options.html.brhumphe commentedon Oct 19, 2016
Why isn't it the default for the others? And why doesn't
commonjssupportoutFile?mhegazy commentedon Oct 19, 2016
to maintain backward compatibility for user code before TS 1.6. issue #11434 tracks changing the default.
This is not a simple concat procese like in sysmte/amd. commonjs has specific meaning for require/filenames. if you want a module blunder for commonjs, use browserify or wepback.
brhumphe commentedon Oct 19, 2016
So my origional proposal is more or less already how things work, and what tripped me up was an unexpected set of defaults, which this suggestion would not address. I'll go ahead and close it up then.