meta-files在JavaScript软件包中增殖（无论您使用哪种基于节点的或子模型管理方法）。您在香草顶部添加的每种技术都至少包括一个（如果不是更多的话）在项目的最高水平上，在运行时很少使用（如果有的话）。这是Web开发生态系统的疯狂部分之一。

因此，我通常会在自定义package.json字段中合并结构化输入。然后，当运行脚本时，将这些结构写入CI上下文，并将结果文件添加到我们的.gitignore中，以确保在存储库中始终存在一个配置规范的源。

让我们看一些示例！每个都将包括至少一个自定义package.json字段，一个脚本示例，相关的.gitignore内容，以及这如何促进本地开发系统和远程跑步者的直接CI。

JSDOC

这是更直接的情况之一，并直接映射到此处记录的JSDOC配置规范：

https://jsdoc.app/about-configuring-jsdoc.html

这是我可能将其放入package.json文件中的自定义字段。请注意，我们还将一些占位符的田地空白（例如名称，摘要和版权）；我们将在脚本运行时按照脚本运行时的单源真实字段映射这些内容。

  ".jsdoc-conf": {
    "recurseDepth": 3,
    "source": {
      "includePattern": ".+\\.mjs$",
      "exclude": [
        "node_modules"
      ]
    },
    "tags": {
      "dictionaries": [
        "jsdoc"
      ]
    },
    "templates": {
      "systemName": "",
      "systemSummary": "",
      "monospaceLinks": true,
      "default": {
        "outputSourceFiles": false,
        "useLongnameInNav": true
      },
      "copyright": ""
    },
    "plugins": [
      "plugins/markdown"
    ]
  },

然后，我们可以添加一个“文档”脚本条目：

  "scripts": {
    "docs": "node -e \"let pkg = require('./package.json'); pkg['.jsdoc-conf']['templates']['systemName'] = pkg['name']; pkg['.jsdoc-conf']['templates']['systemSummary'] = pkg['description']; pkg['.jsdoc-conf']['templates']['copyright'] = pkg['license']; console.log(JSON.stringify(pkg['.jsdoc-conf']))\" > .jsdoc-conf.json & jsdoc -R ./README.md -c ./.jsdoc-conf.json -t ./node_modules/foodoc/template ./index.mjs"
  }

这是一团糟，但是我们只需要定义一次即可。让我们分解发生的事情：

1. 首先，节点命令用于加载package.json本身的声明

2. 我们映射系统名称的模板参数；系统摘要；和包装名称的版权；描述;和许可字段，分别

3. 我们可以将“ .jsdoc-conf”属性下的对象写入.jsdoc-conf.json文件；该文件已添加到我们的.gitignore中，因此我们在存储库中跟踪的任何时间都只有一个权威规范

4. 然后，我们可以运行jsdoc命令，传递临时配置以及其他参数（例如我们的splash page content for Splash page contents以及通往模板的路径）

5. 在这种情况下，我们还将其直接指向我们的索引；可以从“主要”值中提取这一点，但是在单文件JavaScript模块生命周期

的过程中不会更改。

要运行此脚本，我们需要确保Dev依赖项包括“ JSDOC”和（选择）我们的模板“ foodoc”。然后，我们可以从命令行进行测试：

> yarn add -D jsdoc foodoc
> yarn run docs

如果成功的话，我们应该看到一个生成的out/文件夹，我们可以直接打开包装文档以浏览和验证。

CI作业将简单地安装，然后将“文档”脚本纱。我们还需要确保将.jsdoc-conf.json文件和“ out/”文件夹添加到我们的.gitignore文件中。最后，我们可以轻松地将out/的内容复制到Gitlab页面挂钩（如果需要的话），以便于转录到托管/发布的HTML参考。

茉莉花

茉莉花配置选项在这里记录：

https://jasmine.github.io/setup/nodejs.html

我实际上从package.json中写出两个字段；一个是Jasmine.json配置文件的内容，另一个实际上是JavaScript的几个样板代码，用于在索引源代码中引导到测试用例中。您不必采用遵循相同技术的方法，但是就像我更喜欢将JSON合并到一个文件中一样，我更喜欢将测试脚本打包到模块本身中。这是可能使用此方法的索引源代码的基本示例。

要使用这种方法，我们首先将样板代码添加到package.json中，为“ .Jasmine-Tests”：

  ".jasmine-tests": [
    "import { JUnitXmlReporter } from \"jasmine-reporters\";",
    "import index from \"./index.mjs\";",
    "const junitReporter = new JUnitXmlReporter({ \"consolidateAll\": true });",
    "jasmine.getEnv().addReporter(junitReporter);",
    "describe(\"thismodule\", () => {",
    " Object.keys(index.__tests__).forEach(k => {",
    "   it(k, index.__tests__[k]);",
    " });",
    "});"
  ],

虽然密集，但此样板代码中有几件事：

1. 我们使用JUNIT风格的XML记者来确保通过随后的分析通过（包括覆盖范围，以及对于Gitlab，对于自动CI报告挂钩）的测试结果

2. 然后导入索引源

3. 然后实例化记者

然后，使用茉莉花来获取环境，并使用我们创建的记者
将其扩展

4. 然后，我们描述/定义了一个顶级测试闭合，该测试通过“ __-Tests__”导出字段中的每个键值对；然后将每个测试转发到茉莉“ it（）”处理程序

我们正在添加的新“测试”脚本条目将看起来像这样：

  "scripts": {
    ...
    "test": "node -e \"console.log(JSON.stringify(require('./package.json')['.jasmine-conf']))\" > .jasmine-conf.json & node -e \"console.log(require('./package.json')['.jasmine-tests'].join('\\n'))\" > .jasmine-tests.mjs & jasmine --config=.jasmine-conf.json",
  }

这是此脚本的细分：

1. 首先，我们将茉莉配置写入.jasmine-conf.json文件。像其他配置一样，已将其添加到我们的.gitignore文件中，以确保在package.json文件中有一个真实的来源；我们将在片刻

中浏览这些领域

2. 我们从上方写下测试样板代码到.jasmine-tests.mjs文件，在我们的Runner Environment中可以执行

3. 最后，茉莉花本身是运行的，我们通过了我们已经写出的特定配置文件

最后，让我们看一下我们在package.json属性中包含的配置“ .jasmine-conf”：

  ".jasmine-conf": {
    "spec_dir": ".",
    "spec_files": [
      ".jasmine-tests.mjs"
    ],
    "env": {
      "stopSpecOnExpectationFailure": false,
      "random": false
    }
  },

在这种情况下，我们的测试规范（“ Spec-Files”）只是我们已经写出的自举代码。我们从当前 /顶级文件夹运行这些测试，因此不需要其他文本内容。< / p>

添加了这三个更改后，我们可以简单地从命令行中运行脚本，假设我们还已经安装了Dev依赖项（“ Jasmine”和“ Jasmine-Reporters”）。

> yarn add -D jasmine jasmine-reporters
> yarn run test

C8

c8配置主要是通过项目的github页面记录在readme中：

https://github.com/bcoe/c8#readme

添加覆盖范围现在相对简单，主要是因为我们可以重复使用上面定义的脚本。就像以前一样，我们现在在包装中添加一个“ .c8-conf”字段。JSON：

  ".c8-conf": {
    "exclude-after-remap": true,
    "include": [
      "index.mjs"
    ],
    "exclude": [
      ".jasmine-tests.mjs"
    ],
    "reporter": [
      "cobertura",
      "text"
    ]
  },

覆盖范围主要针对（在这种情况下）单个顶级索引源进行评估。我们忽略了上一个阶段中编写的临时测试样板代码，并确保生成机器可读（Cobertura）输出。这极大地促进了（例如）Gitlab CI跑步者自动消费覆盖范围。

这是我们添加到软件包的“覆盖范围”脚本。

  "scripts": {
    ...
    "coverage": "node -e \"console.log(JSON.stringify(require('./package.json')['.c8-conf']))\" > .c8rc.json & c8 yarn run test"
  }

现在您可能可以解释我们在做什么：

1. “ .c8-conf”属性的内容写入文件，该文件再次由我们的.gitignore文件提供。

2. 然后，我们通过纱线直接运行C8与“测试”脚本运行

然后可以从命令行或CI规范中调用此脚本：

yarn add -D c8
yarn run coverage

结论

还有许多其他简单的方法可以在CI工作中找到适度的JavaScript软件包：

，但仅关注这些案例会通过消除：

• JSDOC配置JSON（在添加包装属性的程序挂钩时）

• 茉莉花配置JSON

• 茉莉花顶级跑步者样板代码或“ spec”

• C8配置JSON用于覆盖范围评估

，但是当您查看“脚本”定义时，这有点令人费解。这值得添加吗？

我认为，是。 “你怎么能从中获得最大最大收益？”我认为是一个很好的指导原则。

您看到的，当我们有多种真相来源的真相来源，例如测试配置，软件包描述等。总是有可能这些真相会差异，这对权威价值有明显的影响，这也使我感到非常紧张。当我们可以简化模板新的JavaScript软件包，开发人员需要利用模板时，我们还会激励CI推出。最后，当然，对于那些具有强大强迫症倾向的人，我们可以简单地跟踪更少的简单包装内容的文件（更不用说当我们想在验证后删除它们时获得令人满意的git clean -Xfd。

毕竟，这看起来更好吗？

公平地说，您可以包括的更多内容。预兆候选人都是宝贝投入，跨性型配置，部署或更高级别的测试结构以及缩小/混淆输入的候选者。但是，这些方法与我们在这里看到的示例不会有太大变化。