简体   繁体   English

尝试通过 --experimental-loader 选项使用 mocha、ES6 模块和 ts-node

[英]Trying to use mocha, ES6 modules, and ts-node with the --experimental-loader option

I'm trying to get the ts-node option --experimental-loader working along with mocha, and having no luck.我试图让 ts-node 选项--experimental-loader与 mocha 一起工作,但没有运气。 Until I started trying to compile ES6 modules, I used to be able to run mocha tests this way:在我开始尝试编译 ES6 模块之前,我曾经能够以这种方式运行 mocha 测试:

"test": "nyc --reporter=html mocha --require ts-node/register src/**/*.spec.ts"

That doesn't work anymore when generating ES6 modules.这在生成 ES6 模块时不再起作用。

I'd use the TS_NODE_COMPILER_OPTIONS='{\"module\": \"commonjs\" }' solution for testing, but that won't work for me because of another complication: I'm generating ES6 modules as a first step in my build, but also generating ES5/CommonJS modules using webpack and babel.我会使用TS_NODE_COMPILER_OPTIONS='{\"module\": \"commonjs\" }'解决方案进行测试,但由于另一个复杂性,这对我不起作用:我生成 ES6 模块作为第一步我的构建,使用 webpack 和 babel 生成 ES5/CommonJS 模块。 That last step doesn't work unless I add .js to the end of my local TypeScript import statements.除非我将.js添加到本地 TypeScript import语句的末尾,否则最后一步不起作用。

But adding those .js extensions turns out to break the TS_NODE_COMPILER_OPTIONS='{\"module\": \"commonjs\" }' solution, which will work, however, if I go back and delete all of the .js extensions.但是添加这些.js扩展名会破坏TS_NODE_COMPILER_OPTIONS='{\"module\": \"commonjs\" }'解决方案,但是,如果我返回 go 并删除所有.js扩展名,则该解决方案将起作用。 I obviously don't want a test and build process where I have to keep going back and forth between adding and removing those extensions.我显然不想要一个测试和构建过程,我必须在添加和删除这些扩展之间来回切换。

To simplify for now, I've taken out nyc, and I'm trying to run tests like this:为了简化现在,我已经删除了 nyc,并且我正在尝试运行这样的测试:

mocha -r ts-node/register --experimental-loader ./ts-loader.mjs src/**/*.spec.ts

I get no errors this way, but nothing happens either.这样我没有错误,但也没有任何反应。 It's like the src/**/*.spec.ts doesn't exist.就像src/**/*.spec.ts不存在一样。

My do-nothing (for now) dummy loader looks like this:我的无所事事(目前)虚拟加载程序如下所示:

console.log('ts-loader loaded');

export async function resolve(specifier, context, defaultResolve) {
  console.log('resolve');
  return defaultResolve(specifier, context, defaultResolve);
}

export async function getFormat(url, context, defaultGetFormat) {
  console.log('getFormat');
  return defaultGetFormat(url, context, defaultGetFormat);
}

export async function getSource(url, context, defaultGetSource) {
  console.log('getSource');
  return defaultGetSource(url, context, defaultGetSource);
}

export async function transformSource(source, context, defaultTransformSource) {
  console.log('transformSource');
  return defaultTransformSource(source, context, defaultTransformSource);
}

export function getGlobalPreloadCode() {
  console.log('getGlobalPreloadCode');
  return '';
}

I can tell it gets loaded because the 'ts-loader loaded' message appears, but none of the functions ever get called.我可以告诉它已加载,因为出现了'ts-loader loaded'消息,但没有一个函数被调用。

I've tried other permutations, but just get errors like src/**/*.spec.ts being treated as a literal file name instead of a glob, or errors about modules not being found.我尝试了其他排列,但只是得到像src/**/*.spec.ts这样的错误被视为文字文件名而不是 glob,或者关于未找到模块的错误。

I was hoping to see my loader invoked for every import being handled, and then figuring out how to manipulate the file extensions, but I haven't managed to get that far yet.我希望看到我的加载程序在处理每个import时都被调用,然后弄清楚如何操作文件扩展名,但我还没有做到这一点。 Any suggestions?有什么建议么?

I'm using node v14.15.1.我正在使用节点 v14.15.1。 The full code for my project, with a working build, but broken tests, can be found here: https://github.com/kshetline/tubular_math可以在此处找到我的项目的完整代码,其中包含有效的构建,但测试失败: https://github.com/kshetline/tubular_math

I finally found a solution, although it wasn't along the lines I was originally looking for.我终于找到了一个解决方案,虽然它不是我最初寻找的路线。 I gave up on trying to make mocha happy with the extra .js extensions, and found a way to make webpack happy without them.我放弃了尝试让 mocha 对额外的.js扩展感到满意,并找到了一种方法让 webpack 在没有它们的情况下感到满意。 So...所以...

import { Angle, Mode, Unit } from './angle.js';

...went back to... ……回到……

import { Angle, Mode, Unit } from './angle';

My test script looks like this:我的测试脚本如下所示:

  "scripts": {
    "build": "rimraf dist/ && tsc && webpack && webpack --env target=umd",
    "prepublishOnly": "npm run build",
    "lint": "eslint 'src/**/*.ts'",
    "test": "TS_NODE_COMPILER_OPTIONS='{\"module\":\"commonjs\"}' nyc --reporter=html mocha --require ts-node/register src/**/*.spec.ts"
  },

And finally, most importantly, I figured out how to make webpack 5.x (4.x didn't have this issue) happy with local JavaScript imports that don't have a .js extension, which webpack now otherwise insists upon if your package.json says "type": "module" :最后,最重要的是,我想出了如何使 webpack 5.x(4.x 没有这个问题)对没有.js扩展名的本地 JavaScript 进口感到满意,否则 Z424516CA53B4AD4BEF837EDA 现在坚持package.json"type": "module"

    module: {
      rules: [
        { test: /\.js$/, use: 'babel-loader', resolve: { fullySpecified: false } }
      ]
    }

...where setting fullySpecified to false is the key to the solution. ...将fullySpecified设置为false 是解决方案的关键。

UPDATE : The above example was done working on a deliberately simple project, something easy for a starter to generate an npm package with ESM modules.更新:上面的示例是在一个故意简单的项目上完成的,对于初学者来说很容易生成带有 ESM 模块的 npm package。 Now that I'm trying something a little more advanced, I've run into a snag again running unit tests.现在我正在尝试一些更高级的东西,我再次遇到了运行单元测试的障碍。 As soon as a *.spec.ts file directly or indirectly imports external code, module loading fails.一旦 *.spec.ts 文件直接或间接导入外部代码,模块加载就会失败。 I can only test code with no external dependencies until I figure out how to fix that problem.在弄清楚如何解决该问题之前,我只能测试没有外部依赖项的代码。 Apparently using "TS_NODE_COMPILER_OPTIONS='{\"module\":\"commonjs\"}' is only letting me go one level deep into fixing the basic problem with running mocha along with ts-node.显然使用"TS_NODE_COMPILER_OPTIONS='{\"module\":\"commonjs\"}'只是让我 go 深入解决与 ts-node 一起运行 mocha 的基本问题。

声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM