【问题标题】:Developing a requirejs-exported library in TypeScript在 TypeScript 中开发一个 requirejs 导出的库
【发布时间】:2016-01-21 00:52:29
【问题描述】:

抱歉,如果这个问题有点不集中/漫无边际,但我在这里真正遇到的是几个相互关联的问题,我想一次性提出。

假设我正在开发一个名为foo 的库,它由文件foo.tsbar.tsbaz.ts 组成。 foo.ts 是库的根,即它依赖于其他两个并导出依赖应用程序可能需要的所有功能。还假设我想让这个库作为 AMD 可加载模块提供。

在 TypeScript 中构建这段代码的正确方法是什么?以下是我能想到的方法:

  1. 在整个文件中使用/// <reference path="..."/>,然后使用--out combined.js 将它们组合成一个大库。但是如果我这样做,我看不到如何使组合输出作为 AMD 模块在下游可用。如果我将export 语句添加到foo 模块,它对组合文件没有影响,只会生成foo.js 的requirejs 包装版本。因此,通过--out combined.js 组合内部模块然后通过export 使组合结果的某些部分可用似乎并不简单。我是否应该使用其他工具将串联结果包装在 AMD 样板文件中,避开 TypeScript 的 import/export 功能?

  2. 使foo.tsbar.tsbaz.ts 成为所有外部模块,让它们相互依赖,例如使用import bar = require('./bar');,并让 foo.ts 导出一个模块,该模块仅包含作为库公共 API 一部分的 barbaz 的一部分。如果我走这条路,那么默认情况下,由于我们使用的是 AMD 模块,所有文件都将单独下载,即使它们高度相互依赖,这似乎不太理想。但是我可以使用 requirejs 优化器将生成的单个模块组合成一个大模块。但是,如果使用该库的应用程序也是用 TypeScript 编写的,并且想要使用它的声明,那么它应该在哪里查找呢?当使用 (1) 中的 --out combined.js 选项时,还可以为库获得组合的 .d.ts,但是在使用外部模块时,我看不到如何执行此操作。下游应用程序代码是否应该进入源目录并获取单独的声明文件,即foo.d.tsbar.d.tsbaz.d.ts?我应该手动创建一个引用所有自动生成的单例.d.tss 的主声明文件吗?

【问题讨论】:

    标签: typescript


    【解决方案1】:

    这就是我要做的。使用--out lib.js --declaration 编译会标记除foo.ts 之外的所有文件。然后使用声明创建foo.ts 例如假设:

    bar.ts:

    module Foo{
       export class Bar{
       }
    }
    

    baz.ts

    module Foo{
       export class Baz{
       }
    }
    

    你会得到的声明文件(由于--declaration标志)是:

    module Foo{
      export class Bar{
       }
      export class Baz{
       }
    }
    

    所以你可以创建Foo.ts 为:

    /// <reference path="lib.d.ts"/>
    declare module "Foo"{
      export = Foo;
    }
    

    然后硬编码一个lib.dist.js来加载--out js文件并导出到amd:

    define([require,'lib'],function(){
        return Foo;
    });
    

    更新 如果您需要依赖第三方库,请在Foo.ts 中使用&lt;amd-depenedency,并在其他部分中自己使用Foo.ts

    【讨论】:

    • 两个问题:1) 我不确定我是否理解您所描述的Foo.ts 文件的意义……lib.d.ts 文件不是已经完成了吗? 2)lib.dist.js 如何“加载”--out js 文件? lib.js 文件本身必须以某种方式包装在 requirejs 样板文件中。我可以使用grunt-requirejs 任务来做到这一点,但所有这些的副作用是源映射不再工作:(
    • 我也可以将 lib.js 视为具有全局常量的遗留库并使用 shim 将其导出,但这也很不幸,因为它将责任推给了库的使用者。
    • 啊,我明白了Foo.ts的意思,为下游打字稿代码制作一个外部模块来导入。
    • 啊,我明白了 Foo.ts 的意义,为下游打字稿代码制作一个外部模块来导入。 : 是的
    • 好的,我想我理解你的解决方案,只要我的库没有自己的 AMD 依赖项,它就可以工作。但是假设我的库需要 JQuery ......我怎么能表示这种依赖关系?如果不强迫图书馆的使用者为它写一个 shim,我看不出有什么办法。
    【解决方案2】:

    新方法!忘记引用,只需将 tsconfig.json 文件放在项目的根目录下,所有内容都可以正常工作而不会发生冲突。

    【讨论】:

      猜你喜欢
      • 2019-11-18
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2017-07-13
      • 2016-05-04
      • 1970-01-01
      • 2017-08-07
      • 2017-05-13
      相关资源
      最近更新 更多