fix: do not pull esbuild 0.11 into every adapter via @alcalzone/esbuild-register by hombach · Pull Request #751 · ioBroker/testing

hombach · 2026-10-31T11:54:27Z

Update: Following @AlCalzone's review, the PR now switches the integration tests to tsx (node --import tsx) instead of @alcalzone/esbuild-register (e66a457). The npm override described below is no longer used; the test dir installs tsx: '^4.20.0' next to js-controller. The original description is kept below for context, see Current state (tsx) at the bottom.

Fixes #750

Changes

Removed @alcalzone/esbuild-register from dependencies (and its entries @alcalzone/esbuild-register, esbuild@0.11.23 and jsonc-parser from package-lock.json). @iobroker/testing never imports it. It is only needed in the integration test directory, where controllerSetup.ts already installs it.
controllerSetup.ts: moved the generated test directory package.json into a new method createTestDirPackageJson() and added a scoped npm override:
```
"overrides": {
  "@alcalzone/esbuild-register": { "esbuild": "^0.25.0" }
}
```
The scoped form (instead of a top-level "esbuild" override) leaves an esbuild dependency of the adapter under test alone. allowScripts stays the same.
Added unit tests for the generated package.json (dependencies, overrides, allowScripts).
Updated build/ and added a CHANGELOG entry under **WORK IN PROGRESS** (no version bump).

Testing

npm run build, npm run lint and npm test pass (66 tests, 3 of them new).
Generated package.json installed in an empty directory (npm 11 and npm 12): npm ls esbuild shows only @alcalzone/esbuild-register@2.5.1-1 → esbuild@0.25.12. node -r @alcalzone/esbuild-register some.ts works (enum, private field, source-mapped stack trace).
Test directory from an earlier run that already has esbuild 0.11.23 installed: after rewriting package.json and running npm i --omit=dev (with the lockfile deleted, as prepareTestDir() does), esbuild is updated to 0.25.12.
Adapter whose own dependencies include esbuild@0.24.2: with the scoped override, the adapter keeps 0.24.2 and esbuild-register gets 0.25.12. A top-level override would have changed both.
Adapter (pure JS, ts-node unit tests) installed against this branch as a tarball: no esbuild 0.11 in its tree, npm audit reports no esbuild finding, and test:ts and test:package pass. The integration test creates the test directory with the override (esbuild@0.25.12). It then fails at adding the adapter instance only because http://download.iobroker.net/sources-dist.json currently returns HTTP 500. That failure is unrelated to this change.

Note

Adapters that use @alcalzone/esbuild-register in their own scripts (for example in .mocharc) and relied on getting it through @iobroker/testing need to add it to their own devDependencies. The adapters I checked (ioBroker.history, ioBroker.wattcycle) already list it directly.

Current state (tsx)

Changes

Removed @alcalzone/esbuild-register from dependencies (and its entries @alcalzone/esbuild-register, esbuild@0.11.23 and jsonc-parser from package-lock.json). @iobroker/testing never imports it.
Integration tests now start TypeScript adapters with tsx (node --import tsx) instead of node -r @alcalzone/esbuild-register, as suggested by @AlCalzone. tsx also runs TypeScript files inside node_modules and depends on a current esbuild, so no override is needed.
controllerSetup.ts: moved the generated test directory package.json into a new method createTestDirPackageJson(). It installs tsx: '^4.20.0' next to js-controller. allowScripts stays the same (esbuild is now used by tsx).
Added unit tests for the generated package.json (dependencies, no overrides, allowScripts).
Updated build/ and added a CHANGELOG entry under **WORK IN PROGRESS** (no version bump).

Testing

npm run build, npm run lint and npm test pass (66 tests).
End-to-end with a minimal TypeScript adapter (main: src/main.ts, installed into the test dir's node_modules) on Node 22.23 against js-controller dev: the adapter starts with --import tsx and the integration tests pass.
npm ls esbuild in the generated test dir: tsx → esbuild@0.28.2. esbuild@0.11.23 is still present via js-controller's own dependency on @alcalzone/esbuild-register; adapters' own dependency trees no longer contain it.

…ld-register @alcalzone/esbuild-register is only used inside the integration test directory, where controllerSetup already installs it. Remove it from the dependencies of @iobroker/testing, so adapters no longer get esbuild@0.11.23 (GHSA-67mh-4wv8-2f99), which Dependabot cannot update. In the generated package.json of the test directory, force esbuild@^0.25.0 for @alcalzone/esbuild-register via a scoped npm override.

mcm1957 · 2026-10-31T11:57:57Z

@GermanBluefox

Does it really make sense to use OVERRIDES here. Overrides most like cause problems. I would suggest to contact @AlCalzone to adapt it's dependencies instead of using overrides

hombach · 2026-10-31T12:22:20Z

@mcm1957 Hi Martin yes, of course this would make sence. @AlCalzone didn't change anything in his Repo since >5 years - so this could be an easier way.
My goal is to get rid of the error messages in my adapters... and I didn't want to put the override in all of them.
An override in @iobroker/testing is the first point to fix it all at once, of course, @alcalzone/esbuild-register would be the better one to fix it.

mcm1957 · 2026-10-31T12:32:44Z

@AlCalzone did SEVERAL updates for the releasescript within the last months. So he will for sure update this repo too if required. :-)

I'll ping him ...

hombach · 2026-10-31T13:13:16Z

@mcm1957 @AlCalzone I opened AlCalzone/esbuild-register#1: it widens the esbuild range to >=0.25.0 <1 and bumps the version to 2.5.2. That still matches the existing ^2.5.1-1 ranges in testing, js-controller and dev-server, so once it is released, an npm update resolves the alert everywhere without any other release. Tests pass on Node 22, 24 and 26 with esbuild 0.25 and 0.28.

AlCalzone

@alcalzone/esbuild-register is no longer state of the art. Today, tsx is the better alternative. It also runs TypeScript files inside node_modules and depends on a current esbuild, so the override isn't needed.

Besides the suggestions below, the adapter needs to be started with tsx in src/tests/integration/lib/harness.ts:

const args = isTypeScript
    ? ['--import', 'tsx', mainFileRelative, '--console']
    : [mainFileRelative, '--console'];

If other repos need modification, I recommend switching them to tsx similarly.

AlCalzone · 2026-11-02T10:17:02Z

+                [`${this.appName}.js-controller`]: controllerVersion,
+                // @alcalzone/esbuild-register is needed to run TypeScript adapters
+                '@alcalzone/esbuild-register': '^2.5.1-1',
+            },
+            // @alcalzone/esbuild-register@2.5.1-1 (the latest version) depends on esbuild@^0.11.5,
+            // which is affected by GHSA-67mh-4wv8-2f99. Force a fixed esbuild version, but only
+            // for esbuild-register, so an esbuild dependency of the adapter itself is not touched
+            overrides: {
+                '@alcalzone/esbuild-register': {
+                    esbuild: '^0.25.0',
+                },
+            },
+            // npm >= 12 blocks dependency install scripts by default:
+            // - js-controller needs its install script ("setup first") to create the database
+            // - esbuild (used by @alcalzone/esbuild-register) downloads its binary


Suggested change

[`${this.appName}.js-controller`]: controllerVersion,

// @alcalzone/esbuild-register is needed to run TypeScript adapters

'@alcalzone/esbuild-register': '^2.5.1-1',

},

// @alcalzone/esbuild-register@2.5.1-1 (the latest version) depends on esbuild@^0.11.5,

// which is affected by GHSA-67mh-4wv8-2f99. Force a fixed esbuild version, but only

// for esbuild-register, so an esbuild dependency of the adapter itself is not touched

overrides: {

'@alcalzone/esbuild-register': {

esbuild: '^0.25.0',

},

},

// npm >= 12 blocks dependency install scripts by default:

// - js-controller needs its install script ("setup first") to create the database

// - esbuild (used by @alcalzone/esbuild-register) downloads its binary

// tsx is needed to run TypeScript adapters

tsx: '^4.20.0',

},

// npm >= 12 blocks dependency install scripts by default:

// - js-controller needs its install script ("setup first") to create the database

// - esbuild (used by tsx) downloads its binary

AlCalzone · 2026-11-02T10:17:02Z

+    it('installs the requested JS-Controller version and esbuild-register', () => {
+        const packageJson = new ControllerSetup(adapterDir, testDir).createTestDirPackageJson('7.2.2');
+        expect(packageJson.dependencies).to.deep.equal({
+            'iobroker.js-controller': '7.2.2',
+            '@alcalzone/esbuild-register': '^2.5.1-1',
+        });
+    });
+
+    it('forces a fixed esbuild version (GHSA-67mh-4wv8-2f99) for esbuild-register only', () => {
+        const packageJson = new ControllerSetup(adapterDir, testDir).createTestDirPackageJson('dev');
+        expect(packageJson.overrides).to.deep.equal({
+            '@alcalzone/esbuild-register': {
+                esbuild: '^0.25.0',
+            },
+        });
+    });
+


Suggested change

it('installs the requested JS-Controller version and esbuild-register', () => {

const packageJson = new ControllerSetup(adapterDir, testDir).createTestDirPackageJson('7.2.2');

expect(packageJson.dependencies).to.deep.equal({

'iobroker.js-controller': '7.2.2',

'@alcalzone/esbuild-register': '^2.5.1-1',

});

});

it('forces a fixed esbuild version (GHSA-67mh-4wv8-2f99) for esbuild-register only', () => {

const packageJson = new ControllerSetup(adapterDir, testDir).createTestDirPackageJson('dev');

expect(packageJson.overrides).to.deep.equal({

'@alcalzone/esbuild-register': {

esbuild: '^0.25.0',

},

});

});

it('installs the requested JS-Controller version and tsx', () => {

const packageJson = new ControllerSetup(adapterDir, testDir).createTestDirPackageJson('7.2.2');

expect(packageJson.dependencies).to.deep.equal({

'iobroker.js-controller': '7.2.2',

tsx: '^4.20.0',

});

});

…d-register As suggested in the review of ioBroker#751: tsx is the current state of the art, also runs TypeScript files inside node_modules and depends on a current esbuild, so no npm override is needed in the test directory anymore.

hombach · 2026-11-02T18:28:22Z

Thanks @AlCalzone, that's much cleaner! I switched the PR to tsx as suggested (e66a457): the test dir now gets tsx: '^4.20.0' instead of @alcalzone/esbuild-register, the override is gone, and TypeScript adapters are started with node --import tsx. Build, lint and unit tests pass, and an end-to-end run with a small TypeScript adapter (main file in node_modules, Node 22) works.

One observation: the generated test dir still contains esbuild@0.11.23, because js-controller itself (7.2.5 and 8.0.0-alpha) depends on @alcalzone/esbuild-register. Adapters are no longer affected, but switching js-controller to tsx as well would remove it completely.

GermanBluefox · 2026-11-04T18:03:04Z

Please say me, when should I look at it.

hombach · 2026-11-07T12:16:38Z

@GermanBluefox my adapters have been tested against the PR. Currently GitHub would need another trigger from your side to finish the tests (last macos is missing caused by the known GitHub issues last days)

If I could assist in testing - tell me what adapter(s) should be tested against this PR - I could fork them and let the BOT do all these tests.

Copilot

🟡 Changes recommended

The tests do not exercise startAdapter(), leaving the new TypeScript loader arguments, adapter working directory, and unchanged JavaScript startup behavior without regression coverage.

1 open issue

Add startAdapter tests for TypeScript loader arguments · New

What changed in this PR

This PR addresses #750 by removing the dependency that brings legacy esbuild into consuming adapters and switching TypeScript integration-test startup to tsx.

Changes:

Remove @alcalzone/esbuild-register and its dependencies from the library’s dependency tree.
Install tsx in the integration test directory and launch TypeScript adapters with node --import tsx.
Add generated-package tests and update compiled output, documentation, and the changelog.

File	Description
src/tests/integration/lib/harness.ts	Switch TypeScript startup to `tsx`.
src/tests/integration/lib/controllerSetup.ts	Extract package generation and install `tsx`.
src/tests/integration/lib/controllerSetup.test.ts	Test dependencies, absent overrides, and script permissions.
package.json	Remove the legacy loader dependency.
package-lock.json	Remove the loader and its dependency entries.
CLAUDE.md	Document the updated startup command.
CHANGELOG.md	Describe the dependency and loader changes.
build/tests/integration/lib/harness.js	Update the compiled launcher.
build/tests/integration/lib/controllerSetup.js	Update compiled test-directory setup.
build/tests/integration/lib/controllerSetup.d.ts	Declare the package-generation method.

_{Review effort: Balanced}

        const command = isWindows ? 'node.exe' : 'node';
        const args = isTypeScript
-            ? ['-r', '@alcalzone/esbuild-register', mainFileRelative, '--console']
+            ? ['--import', 'tsx', mainFileRelative, '--console']


hombach · 2026-11-08T13:02:42Z

Thanks for the review — added in d927412.

Our earlier practical tests already covered real adapter startup, including a TypeScript adapter running through tsx. The new unit tests now explicitly verify the loader arguments, relative entry point and installed adapter working directory, plus unchanged JavaScript startup.

I repeated the checks with the freshly built PR package on Node 22.23.4 and 24.22.2. All passed on both versions:

Library: build/check/lint and 68 unit tests.
TypeScript smoke: 2 integration tests with js-controller 7.2.5, verifying actual tsx startup, working directory, a written state and orderly shutdown.
go-e: build/lint, 217 unit tests, 61 package tests and the integration test. This adapter uses compiled JavaScript.

npm 12/allowScripts was not covered.

hombach · 2026-11-08T13:21:02Z

@GermanBluefox I also tested two more adapters against the freshly built PR package (d927412) on both Node 22.23.4 and 24.22.2, using js-controller 7.2.5:

tibberlink 7.4.0: 89 unit tests, 61 package tests and 1 integration test per Node version.
chargemaster 0.16.1: 18 unit tests, 61 package tests and 1 integration test per Node version.

Build, type checking and lint also pass for both adapters. These integration tests verify startup without real configuration, not live operation. Both adapters use compiled JavaScript; the separate TypeScript smoke test covers actual tsx startup.

Could you please re-run the checks for the updated PR?

Copilot

🟢 Approval recommended

No active review issues block approval of the migration from the esbuild-based loader to test-local tsx.

1 open issue

Add startAdapter tests for TypeScript loader arguments

_{Review effort: Balanced}

hombach mentioned this pull request Oct 31, 2026

fix(deps): allow esbuild >=0.25.0 <1 (GHSA-67mh-4wv8-2f99) AlCalzone/esbuild-register#1

Closed

AlCalzone reviewed Nov 2, 2026

View reviewed changes

GermanBluefox requested a balanced review from Copilot November 8, 2026 04:40

Copilot started reviewing on behalf of GermanBluefox November 8, 2026 04:40

View session

Copilot AI reviewed Nov 8, 2026

View reviewed changes

Comment thread src/tests/integration/lib/harness.ts

const command = isWindows ? 'node.exe' : 'node';

const args = isTypeScript

? ['-r', '@alcalzone/esbuild-register', mainFileRelative, '--console']

? ['--import', 'tsx', mainFileRelative, '--console']

test: cover TypeScript and JavaScript adapter startup arguments

d927412

GermanBluefox requested a balanced review from Copilot November 8, 2026 15:03

Copilot started reviewing on behalf of GermanBluefox November 8, 2026 15:04

View session

Copilot AI reviewed Nov 8, 2026

View reviewed changes

GermanBluefox merged commit 95a8088 into ioBroker:master Nov 8, 2026
14 checks passed

Conversation

hombach commented Oct 31, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Changes

Testing

Note

Current state (tsx)

Changes

Testing

Uh oh!

mcm1957 commented Oct 31, 2026

Uh oh!

hombach commented Oct 31, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

mcm1957 commented Oct 31, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

hombach commented Oct 31, 2026

Uh oh!

AlCalzone left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

AlCalzone Nov 2, 2026

Choose a reason for hiding this comment

Uh oh!

AlCalzone Nov 2, 2026

Choose a reason for hiding this comment

Uh oh!

hombach commented Nov 2, 2026

Uh oh!

GermanBluefox commented Nov 4, 2026

Uh oh!

hombach commented Nov 7, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

🟡 Changes recommended

Uh oh!

hombach commented Nov 8, 2026

Uh oh!

hombach commented Nov 8, 2026

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

🟢 Approval recommended

Uh oh!

Uh oh!

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

hombach commented Oct 31, 2026 •

edited

Loading

hombach commented Oct 31, 2026 •

edited

Loading

mcm1957 commented Oct 31, 2026 •

edited

Loading

AlCalzone left a comment •

edited

Loading

hombach commented Nov 7, 2026 •

edited

Loading