Should the index.ts be resolved by TypeScript as default module file?

前端 未结 1 584
感情败类
感情败类 2021-01-04 13:03

I am trying to get work the module resolution under typescript.

If I have:

/modulename/index.ts

should it be resolved by:



        
相关标签:
1条回答
  • 2021-01-04 13:46

    It depends primarily on the --moduleResolution flag (compilerOptions.moduleResultion in tsconfig.json)

    Automatic resolution of a directory to a file named index in that directory is a NodeJS convention. This convention propagated to client-side development but it remains a convention nevertheless. It is not part of the ECMAScript module specification or the AMD specification.

    When specifying --moduleResolution node TypeScript will follow this convention.

    Additionally, when the --module flag (compilerOptions.module in tsconfig.json) is set to commonjs this convention is applied automatically even in the absence of the --moduleResolution flag.

    Note that the setting applies to both application code and to dependencies in directories such as node_modules, jspm_packages, and bower_components.

    While it makes the most sense for CommonJS projects, setting --moduleResolution node can be advantageous in other module formats as it aids in the resolution of dependencies as well as avoids certain pitfalls the come with the alternative classic resolution mode.

    Be advised however, that loaders such as RequireJS and SystemJS will not automatically pick up this convention in your app source code so use of explicit index files in module specifiers is still recommended when importing your own app code.

    In spite of the CommonJS bent of the --moduleResolution node settings, I still prefer and recommend even though I do not use CommonJS, Webpack, or Browserify in the browser (when I can possibly avoid them).

    My loader of choice is SystemJS, and my package manager of Choice is JSPM, but I still prefer to use the node resolution scheme because it makes importing dependencies easier, thanks in part to JSPM's auto configuring of the SystemJS loader.

    Now, let us move on to --baseUrl as it applies to your scenario.

    You are attempting to import a local module as

    import * as modulename from "modulename";
    

    and have set --module commonjs and --baseUrl / in an attempt an import the local module as if it were a third party package to prepare your codebase for its splitting off into a discrete package. This, I might add, is good planning, so :+10 for that!

    However, if you plan to use a CommonJS modules (something I again advise against for browser only applications), you should most definitely set your "baseUrl" to "." rather than, "/". Even then, tools like the Native NodeJS require function have no support for the baseUrl concepts that originated in the browser tooling world. Webpack however, does support it.

    At any rate, to load modules that are part of your own source code using a module specifier that is not a relative or absolute URL, I recommend the following regardless (be aware of loader requirements!):

    1. Set "baseURl" to "."
    2. Set "moduleResolution" to "node",
    3. Set "module" explicitly to "commonjs", "system", or "amd" (I advise against "umd").
    4. If not using "commonjs" under node, consider using "paths" as it allows for some very sophisticated restructuring.
    0 讨论(0)
提交回复
热议问题