javascript - System.import() 和 import() 的区别？

Question

在webpack 1 docs is statement在 webpack 2 中将使用 System.import()对于动态要求:

Luckily, there is a JavaScript API “loader” specification being written to handle the dynamic use case: System.load (or System.import). This API will be the native equivalent to the above require variations.

在那段时间里，整个网络都是 examples使用这个 System.import() .

---

Before releasing webpack 2 , 作者决定更改 System.import()至 import() :

add import() as Code Splitting construct. It should be used instead of System.import when possible. System.import will be deprecated in webpack 2 release (removed in webpack 3) as it's behavior is incorrect according to the spec.

这import()基于 tc39/proposal-dynamic-import规范，您可以阅读更多信息，了解他们为何进行此更改 here .

---

有人可以解释 System.import() 之间的区别吗？和 import() ?

尽管名称不同，用法看起来是一样的:

import(modulePath)
  .then(module => module.default())
  .catch(/* ... */);

System.import(modulePath)
  .then(module => module.default())
  .catch(/* ... */);

但在 webback 2 文档中是:“System.import() 根据规范，行为是不正确的” - 所以这表明 System.import() 之间存在差异和 import() .

Answer 1

这是您要查找的内容:tc39 Proposal for Import

An actual function

Drafts of the Loader ideas collection have at various times had actual functions (not just function-like syntactic forms) named System.import() or System.loader.import() or similar, which accomplish the same use cases.

The biggest problem here, as previously noted by the spec's editors, is how to interpret the specifier argument to these functions. Since these are just functions, which are the same across the entire Realm and do not vary per script or module, the function must interpret its argument the same no matter from where it is called. (Unless something truly weird like stack inspection is implemented.) So likely this runs into similar problems as the document base URL issue for the importModule function above, where relative module specifiers become a bug farm and mismatch any nearby import declarations.