Skip to content

Optional enforcement of explicit namespace imports #11712

Closed

Description

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

  1. Provide a single consistent syntax for importing modules.
  2. 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.

Activity

  1. mhegazy commented on Oct 18, 2016

    @mhegazy
    Contributor

    Every file must have a namespace.

    do not see why this is required.

    Every module must be explicitly imported before use in that file, no exceptions.

    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.

  2. aluanhaddad commented on Oct 18, 2016

    @aluanhaddad
    Contributor

    Benjamin Humpherys (@brhumphe) This sounds like a loader configuration issue. What is your setup?

  3. brhumphe commented on Oct 19, 2016

    @brhumphe
    Author

    This is a repo with the minimal setup.

    Targeting commonjs compiles fine, but when I try to target amd, system, umd, es6, or es2015, tsc gives the error Cannot 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?

  4. blakeembrey commented on Oct 19, 2016

    @blakeembrey
    Contributor

    Benjamin Humpherys (@brhumphe) You need to set moduleResolution: node. It's the default when using commonjs, but not the others. See https://www.typescriptlang.org/docs/handbook/compiler-options.html.

  5. brhumphe commented on Oct 19, 2016

    @brhumphe
    Author

    Why isn't it the default for the others? And why doesn't commonjs support outFile?

  6. mhegazy commented on Oct 19, 2016

    @mhegazy
    Contributor

    Why isn't it the default for the others?

    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.

  7. brhumphe commented on Oct 19, 2016

    @brhumphe
    Author

    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.

  8. locked and limited conversation to collaborators on Jun 19, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Needs More InfoThe issue still hasn't been fully clarified

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions