Repository navigation
Add tests (bring #17 and #18 to main) - #20
Merged
Merged
Conversation
Requiring update-types.js used to run the whole update straight away (npm view, npm i, delete and recopy output/types). Tests need to reuse the real copy logic and exclude list without those side effects. - Main run now only happens when the file is run directly - Export copyFiles and excludeLibs
…ads them
The editor turns a broken type into `any` and hides "cannot find module"
and "property does not exist" from users, so a bad @types/node bump
builds and ships with no warning. That is how Buffer.from() ended up as
`any` after @types/node 24 moved BufferConstructor into buffer.buffer.d.ts.
These tests rebuild the editor's TS program with the TypeScript compiler
API: the same files node-red's monaco.js loads, at the same virtual paths,
with the same compiler options and Setup tab require() shim. Then they
check what the editor would hide.
- Pinned copy of monaco.js knownModules/defaultServerSideTypes in
test/fixtures/editor-modules.js
- Probes for Buffer, NodeJS.TypedArray, timers, URL, util, node, RED.util
and friends in the default libs
- Every knownModules entry resolves when added on the Setup tab, plus
spot checks for common modules
- Known broken entries ('test', 'diagnostics_channel.d') are asserted to
still be broken, so fixing them flags the list for cleanup
- Baseline of members that already fail to resolve (one file per module
means cross-module imports are lost), so a bump can't quietly add more
- Check that the installed typescript matches the version monaco bundles
- `npm test` copies types to a temp folder with update-types.js, so no
build or network is needed
Reverting the fixture to node-red's old default list (no buffer.buffer,
no globals.typedarray) fails 10 tests, including Buffer.from and
NodeJS.TypedArray.
base.d.ts is not in @types/node 20 or 24, and globals.global.d.ts went away in 24. Neither matches anything, so removing them changes nothing in the output. It does let the new bundle test fail on any entry that stops matching, which is how a rename lets an excluded file back in.
When @types/node renamed the V8 inspector protocol to inspector.generated.d.ts, the exclude list kept matching the old name and the ~4400 line file shipped again with no warning. - Every excludeLibs entry must still match a file in @types/node - No excluded file name ships, at any depth - No shipped file declares a module that only excluded files declare (inspector, inspector/promises, repl, punycode, constants) - Every file in node-red's knownModules exists in the build - Baseline of shipped files, so a new or renamed file in @types/node needs a decision instead of shipping by default Taking inspector.generated.d.ts back out of excludeLibs fails two of these, both naming the file.
…ode-red node-red-types/ is copied into node-red, but node-red also takes direct commits to its copies, so the two drift in both directions (node.linkcall() missing here, a stale RED.util.linkcall still in node-red). The type tests also depend on test/fixtures/editor-modules.js matching monaco.js. `npm run test:node-red-sync` compares node-red-types/func.d.ts and util.d.ts with node-red's types/node-red/ copies, and the fixture with the knownModules and defaultServerSideTypes in monaco.js. It reads a local checkout (NODE_RED_DIR) or a ref on GitHub (NODE_RED_REF, default master). It is not part of `npm test`, since the result depends on node-red's state. Putting back the pre-sync func.d.ts from main fails with a diff showing the missing node.linkcall().
`npm run test:build` cleans, runs the full build, then runs every suite against output/ instead of a temp copy of the types, plus a check that the bundle node-red picks up is all there: - editor.js and the editor/ts/json/css/html workers, with a minimum size - a locale file for each of the 13 languages - at least 50 themes, each valid JSON - node and node-red types in output/types Needs network access, like the build itself.
The build can succeed and still hand node-red an editor that breaks at runtime: a worker that never loads, a locale that loads but translates nothing. The type tests also lean on test/lib/editor-env.js behaving like monaco's TS worker, and nothing checked that. `npm run test:browser` (after a build) serves output/ and uses Playwright to check: - editor.js loads with no page errors, and reports the expected monaco and TypeScript versions - the ts, json and css workers report diagnostics and the html worker formats a document - every locale changes the "Format Document" label - monaco's TS worker and editor-env.js give the same hover types and diagnostic codes for the default libs, for the old default list without buffer.buffer/globals.typedarray, and for a few Setup tab modules including the broken 'test' entry editor-env.js now prints types the way the hover does (relative to the user's code), so the two can be compared exactly. pt-br is listed as known untranslated: monaco-editor has published an empty pt-br message table since at least 0.55.1. node-red still ships a working one from 0.52, so it will lose its pt-br translation with this bump. Adds playwright as a devDependency. Chromium comes from `npx playwright install chromium`.
demo.html keeps its own list of type files, and it missed the two companion files @types/node 24 split out. Without them the demo's `const buf = Buffer.from(...)` hovers as `any`, so the manual "should be of type Buffer" check fails on a good build. Now it shows Buffer<ArrayBuffer>.
- unit: `npm test`, no build needed - build: full build with `npm run test:build`, then `npm run test:browser` - node-red-sync: manual only (workflow_dispatch), compares with the node-red ref given as input, default master
Removed reference to monaco-0.57.0 branch in pull request triggers.
Monaco has public getters for its TypeScript and JSON workers but not for CSS and HTML, so editor code can't use those language services for content embedded in another language, e.g. a <style> block in an HTML or Vue template. node-red/node-red#5994 uses this for CSS completion, hover and colours. - monaco.css.getWorker(languageId = "css") for css, scss and less - monaco.html.getWorker(languageId = "html") for html, handlebars, razor and languages added with registerHTMLLanguageService() - Same shape as monaco.json.getWorker(): resolves to (...uris) => Promise<worker>, rejects until the language has been used - Applied in generate-monaco-esm-i18n.js; the build fails if a patch no longer matches, so a Monaco update can't drop it silently - Browser test for both getters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
#17 and #18 merged into their stacked base branches instead of
main. This isadd-testsrebased ontomain, so it brings both over.Tests pass locally (
npm test,test:build,test:browser).