TypeScript应该将index.ts解析为默认模块文件吗? [英] Should the index.ts be resolved by TypeScript as default module file?

问题描述

我正在尝试使用打字稿下的模块分辨率.

如果我有

/modulename/index.ts

应通过以下方式解决

:

import * as modulename from "modulename"

?

我无法正常工作.但是

import * as modulename from "modulename/index"

效果很好.

修改

如 aluan-haddad 所建议，有必要正确配置tsc.

这个为我工作:

{
   ...
   "baseUrl": ".",
   "module": "commonjs",
   "moduleResolution": "node",
   ...
}

修改

请注意，与VS一起使用时，此配置不起作用.如果将其放在外部tsconfig文件中，则编译效果很好，但语言服务无法处理它.如果将其同时放在msconfig(csporj)中，则编译和语言服务将失败.

只有我发现100％可用的一种解决方案是创建类似的内容:

src
   node_modules
      module_being_currently_developed
         submodules

在这种情况下，模块分辨率正常工作.

解决方案

这主要取决于--moduleResolution标志( tsconfig.json 中的compilerOptions.moduleResultion)

将目录自动解析为该目录中名为index的文件是 NodeJS约定 .该约定传播到客户端开发，但是仍然保持约定.它不是ECMAScript模块规范或AMD规范的一部分.

指定--moduleResolution node时，TypeScript将遵循此约定.

此外，当--module标志( tsconfig.json 中的compilerOptions.module)设置为commonjs时，即使没有--moduleResolution标志，该约定也会自动应用./p>

请注意，该设置既适用于应用程序代码，也适用于node_modules，jspm_packages和bower_components等目录中的依赖项.

虽然对于CommonJS项目最有意义，但设置--moduleResolution node在其他模块格式中可能会有所帮助，因为它有助于解析依赖项，并且避免了其他classic解析模式所带来的陷阱./p>

但是请注意，诸如RequireJS和SystemJS之类的加载程序不会在您的应用程序源代码中自动采用此约定，因此在导入您自己的应用程序代码时仍建议在模块说明符中使用显式索引文件.

尽管--moduleResolution node设置使用了CommonJS，但即使在浏览器中不使用CommonJS，Webpack或Browserify时，我仍然更喜欢并推荐(我可能会避免使用它们).

我选择的加载器是SystemJS，而我的选择包管理器是JSPM，但是我仍然更喜欢使用节点解析方案，因为它使导入依赖项更加容易，部分原因是JSPM对SystemJS加载器的自动配置. >

现在，让我们转到适用于您的方案的--baseUrl.

您正在尝试将本地模块导入为

import * as modulename from "modulename";

并已设置--module commonjs和--baseUrl /，以尝试将本地模块当作第三方程序包导入，以准备将其代码库拆分为独立程序包的代码库.我可能会补充说，这是很好的计划，因此:+10！

但是，如果您打算使用CommonJS模块(我再次建议不要使用仅浏览器的应用程序)，则绝对应该将"baseUrl"设置为"."而不是"/".即使那样，诸如Native NodeJS的require函数之类的工具也不支持源自浏览器工具世界的baseUrl概念.但是Webpack确实支持它.

无论如何，要使用不是相对URL或绝对URL的模块说明符来加载属于您自己的源代码的模块，无论如何(无论注意加载程序的要求！)，我都建议以下内容:

1. 将"baseURl"设置为"."
2. 将"moduleResolution"设置为"node"，
3. 将"module"显式设置为"commonjs"，"system"或"amd"(我建议不要使用"umd").
4. 如果未在节点下使用"commonjs"，请考虑使用"paths"，因为它可以进行一些非常复杂的重组.

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

If I have:

/modulename/index.ts

should it be resolved by:

import * as modulename from "modulename"

?

I can't get it work. But

import * as modulename from "modulename/index"

works well.

Edit

as aluan-haddad recommended me it is neccessary to have the tsc configured properly.

This one worked for me:

{
   ...
   "baseUrl": ".",
   "module": "commonjs",
   "moduleResolution": "node",
   ...
}

Edit

Please note this configuration does not work when used with VS. If it is placed in external tsconfig file the compilation works well but language service can't handle it. If its is placed in msconfig (csporj) both, compiltion and language service fails.

Only the one solution I have found to be working for 100% is to create something like:

src
   node_modules
      module_being_currently_developed
         submodules

In this case the module resolution works properly.

解决方案

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.

这篇关于TypeScript应该将index.ts解析为默认模块文件吗?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！