index.ts 是否应该由 TypeScript 解析为默认模块文件?
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
标志也会自动。
请注意,该设置适用于应用程序代码和目录中的依赖项,例如 node_modules
、jspm_packages
和 bower_components
。
虽然它对 CommonJS 项目最有意义,但设置 --moduleResolution node
在其他模块格式中可能是有利的,因为它有助于解决依赖关系并避免替代方案 [=23] 带来的某些陷阱=]分辨率模式。
但是请注意,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,无论如何我都推荐以下内容(注意加载程序要求!) :
- 将
"baseURl"
设置为"."
- 将
"moduleResolution"
设为"node"
,
- 将
"module"
明确设置为 "commonjs"
、"system"
或 "amd"
(我建议不要 "umd"
)。
- 如果不在节点下使用
"commonjs"
,请考虑使用 "paths"
,因为它允许进行一些非常复杂的重组。
您必须在文件夹(模块)名称中添加斜杠,这会将 index.ts 视为文件夹索引。
import * as modulename from "modulename/"
我正在尝试在打字稿下解决模块问题。
如果我有:
/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
标志也会自动。
请注意,该设置适用于应用程序代码和目录中的依赖项,例如 node_modules
、jspm_packages
和 bower_components
。
虽然它对 CommonJS 项目最有意义,但设置 --moduleResolution node
在其他模块格式中可能是有利的,因为它有助于解决依赖关系并避免替代方案 [=23] 带来的某些陷阱=]分辨率模式。
但是请注意,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,无论如何我都推荐以下内容(注意加载程序要求!) :
- 将
"baseURl"
设置为"."
- 将
"moduleResolution"
设为"node"
, - 将
"module"
明确设置为"commonjs"
、"system"
或"amd"
(我建议不要"umd"
)。 - 如果不在节点下使用
"commonjs"
,请考虑使用"paths"
,因为它允许进行一些非常复杂的重组。
您必须在文件夹(模块)名称中添加斜杠,这会将 index.ts 视为文件夹索引。
import * as modulename from "modulename/"