chore: upgrade to mocha@10

[trentm]

From mocha@7. Drop use of ts-mocha in favour of a .mocharc.yml.
This mimicks the same mocha@10 update that was done in opentelemetry-js.git
a long while back.

• The mocha dep has been moved to the top-level and taken out of individual some-workspace/package.json files. I found that this workaround an npm layout issue where we would get many installs of mocha (one in each using workspace dir's own node_modules/). There is prior art: eslint deps are only at the top-level.

Refs: #1826 (comment)

---

This also resolves some errors in npm ls currently on main, that
were introduced in #2269, e.g.:

$ npm ls
├─┬ @opentelemetry/propagator-instana@0.3.2 -> ./propagators/opentelemetry-propagator-instana
│ ├── @types/sinon@17.0.3 invalid: "10.0.20" from propagators/opentelemetry-propagator-instana
│ ├── karma-chrome-launcher@3.1.1 invalid: "3.1.0" from propagators/opentelemetry-propagator-instana
...
├─┬ @opentelemetry/propagator-ot-trace@0.27.2 -> ./propagators/opentelemetry-propagator-ot-trace
│ ├── @types/sinon@17.0.3 invalid: "10.0.20" from propagators/opentelemetry-propagator-ot-trace
...

[david-luna]

TAV errors

-- required packages ["@cucumber/cucumber@8.7.0"]
-- installing ["@cucumber/cucumber@8.7.0"]
-- running test "npm test" with @cucumber/cucumber (env: {})

> @opentelemetry/instrumentation-cucumber@0.9.0 test
> nyc mocha 'test/**/*.test.ts'


 Exception during run: src/instrumentation.ts(258,32): error TS2339: Property 'runAttempt' does not exist on type 'TestCaseRunner'.
Error: src/instrumentation.ts(259,23): error TS2339: Property 'runAttempt' does not exist on type 'TestCaseRunner'.
Error: src/instrumentation.ts(260,52): error TS7019: Rest parameter 'args' implicitly has an 'any[]' type.

it is failing because @cucumber/cucumber@8.7.0 is missing some types. The fact that did not happen before is because I think the former setup is only compiling the test files and the new one is compiling the whole project. This can be reproduced

cd ./plugins/node/instrumentation-cucumber
npm i @cucumber/cucumber@8.7.0
npm run version <-- to have version.ts
npm run compile

> @opentelemetry/instrumentation-cucumber@0.9.0 compile
> tsc -p .

node_modules/@cucumber/cucumber/lib/runtime/stopwatch.d.ts:2:26 - error TS7016: Could not find a declaration file for module 'durations'. '/Users/david/Documents/repos/otel/opentelemetry-js-contrib/node_modules/durations/lib/index.js' implicitly has an 'any' type.
  Try `npm i --save-dev @types/durations` if it exists or add a new declaration (.d.ts) file containing `declare module 'durations';`

2 import { Duration } from 'durations';
                           ~~~~~~~~~~~

src/instrumentation.ts:258:32 - error TS2339: Property 'runAttempt' does not exist on type 'TestCaseRunner'.

258       original: TestCaseRunner['runAttempt']
                                   ~~~~~~~~~~~~

src/instrumentation.ts:259:23 - error TS2339: Property 'runAttempt' does not exist on type 'TestCaseRunner'.

259     ): TestCaseRunner['runAttempt'] {
                          ~~~~~~~~~~~~

src/instrumentation.ts:260:52 - error TS7019: Rest parameter 'args' implicitly has an 'any[]' type.

260       return async function (this: TestCaseRunner, ...args): Promise<boolean> {
                                                       ~~~~~~~


Found 4 errors.

npm ERR! Lifecycle script `compile` failed with error:
npm ERR! Error: command failed
npm ERR!   in workspace: @opentelemetry/instrumentation-cucumber@0.9.0
npm ERR!   at location: /Users/david/Documents/repos/otel/opentelemetry-js-contrib/plugins/node/instrumentation-cucumber

Maybe we should check if there is an option to narrow the compilation to test files only.

[david-luna]

This surfaces one thing we may want to address. The normal flow is to compile 1st then test so what is happening is that we're running tsc on the src/* files each time TAV is running a test on a specific version. I think it would be nice to avoid multiple compilations for TAV.

I did some changes in configuration and it seems to work. Here is a summary:

• remove tests from tsconfig.json
• in tests, import instrumentation from build/src folder instead of src

This way ts-node/register will affect only the files defined in the script nyc mocha 'test/**/*.test.ts' and thanks to source maps if there is an error in the code discovered by tests we get the original TS file. Test file will still be affected by breaking changes in the types of the instrumented modules.

the diff

diff --git a/plugins/node/instrumentation-cucumber/test/cucumber.test.ts b/plugins/node/instrumentation-cucumber/test/cucumber.test.ts
index deffbef3..08203277 100644
--- a/plugins/node/instrumentation-cucumber/test/cucumber.test.ts
+++ b/plugins/node/instrumentation-cucumber/test/cucumber.test.ts
@@ -35,7 +35,7 @@ import * as assert from 'assert';
 import * as fs from 'fs';
 import * as semver from 'semver';

-import { CucumberInstrumentation, AttributeNames } from '../src';
+import { CucumberInstrumentation, AttributeNames } from '../build/src';

 const LIB_VERSION = require('@cucumber/cucumber/package.json').version;
 const hasRunAttempt = semver.gte(LIB_VERSION, '8.8.0');
@@ -45,11 +45,12 @@ instrumentation.enable();
 instrumentation.disable();

 import {
-  IConfiguration,
   loadConfiguration,
   loadSupport,
   runCucumber,
 } from '@cucumber/cucumber/api';
+import { IConfiguration } from './types';
+
 import { PassThrough } from 'stream';

 describe('CucumberInstrumentation', () => {
diff --git a/plugins/node/instrumentation-cucumber/tsconfig.json b/plugins/node/instrumentation-cucumber/tsconfig.json
index c8752378..85b93860 100644
--- a/plugins/node/instrumentation-cucumber/tsconfig.json
+++ b/plugins/node/instrumentation-cucumber/tsconfig.json
@@ -4,5 +4,5 @@
     "rootDir": ".",
     "outDir": "build"
   },
-  "include": ["src/**/*.ts", "test/**/*.ts"]
+  "include": ["src/**/*.ts"]
 }

NOTE: test sources are compiled each time we test a version but I think there is no way to skip this

[trentm]

Idea when working with David on this: See if we can change .mocharc.yml to point to our own wrapper around ts-node/register that passes the "transpileOnly: true" flag -- as ts-mocha was doing: https://github.com/piotrwitek/ts-mocha/blob/53909e045674695b6a5de5f83e6e6583e897db1f/src/index.js#L8-L10

[trentm]

Reviewer note: ts-node offers this way to specify the transpileOnly: true setting (which is what ts-mocha was using)

[david-luna]

nice finding 🎉

[trentm]

7f6a5e4 was to fix an issue (in package-lock.json) due to an npm bug that blew away binary build packages for rollup.

It looks to me like there is the same issue with binary build packages for esbuild, e.g.:

-    "node_modules/@esbuild/linux-x64": {
-      "version": "0.19.12",
-      "resolved": "https://registry.npmjs.org/@esbuild/linux-x64/-/linux-x64-0.19.12.tgz",
-      "integrity": "sha512-B71g1QpxfwBvNrfyJdVDexenDIt1CiDN1TIXLbhOw0KhJzE78KIFGX6OJ9MrtC0oOqMWf+0xop4qEU8JrJTwCg==",
-      "cpu": [
-        "x64"
-      ],
-      "dev": true,
-      "optional": true,
-      "os": [
-        "linux"
-      ],
-      "engines": {
-        "node": ">=12"
-      }
-    },

and nrwl:

-    "node_modules/@nrwl/nx-linux-arm64-gnu": {
-      "version": "15.9.7",
-      "resolved": "https://registry.npmjs.org/@nrwl/nx-linux-arm64-gnu/-/nx-linux-arm64-gnu-15.9.7.tgz",
-      "integrity": "sha512-NYOa/eRrqmM+In5g3M0rrPVIS9Z+q6fvwXJYf/KrjOHqqan/KL+2TOfroA30UhcBrwghZvib7O++7gZ2hzwOnA==",
-      "cpu": [
-        "arm64"
-      ],
-      "dev": true,
-      "optional": true,
-      "os": [
-        "linux"
-      ],
-      "engines": {
-        "node": ">= 10"
-      }
-    },

However, none of the tests are failing. I'd expect the npm run test:browser in "plugins/web/opentelemetry-instrumentation-document-load" to be failing from the missing esbuild binary bits. Why isn't it???

A total guess is because the browser tests in CI are only run with node 16, and perhaps the older npm uses the second half of the package-lock file (which we have pinned to lockfileVersion=2 to support older npm versions), and perhaps the second half of the package-lock file (the part for bwcompat) doesn't have this npm bug where the optional deps for other platforms are removed.

[trentm]

A total guess is because the browser tests in CI are only run with node 16,

I think that guess is wrong. I ran the browser tests in CI with Node.js 22 and they passed. So either:

• esbuild can work without the "optional" binary package dep for the current platform, or
• esbuild isn't actually be exercised by the tests.

(Or I'm missing something.) And same for nrwl.

[trentm]

oof, 36 conflicts in package-lock.json. No way to manually merge that.

[trentm]

Reviewer note: As is common, most of the diff is in the package-lock file. This 22k line diff is down from a larger ~100k line diff in some of the earlier commits.

Grokking package-lock changes is very painful. I wrote a quick package-lock-diff tool that attempts to make it a bit easier to see changes in which packages were installed where (and changes in version, "dev=true"). The tool is here: https://github.com/trentm/npm-tools/blob/main/bin/package-lock-diff

The package-lock-diff for this PR is:
https://gist.github.com/trentm/a510921555cfb194fa607b265a0c83dc

That may still not help anyone reviewing. ;)

[legendecas]

Seems like the diff was due to moving mocha to the top level package.json.