fix: Resolve Web Core CI failures (workflow, tests, and linting)

[jacobsimionato]

Description

This PR addresses multiple issues preventing the web_core tests from running successfully locally and passing in CI.

Description of Changes

• GitHub Actions Workflow Fix: Added the missing runs-on: ubuntu-latest property to the lint job in .github/workflows/web_build_and_test.yml and standardized the paths glob pattern to renderers/web_core/**.
• Test Command Fix: Updated the test and test:coverage scripts in renderers/web_core/package.json to use explicit single-level wildcard patterns (dist/src/v0_8/*/*.test.js dist/src/v0_9/*/*.test.js dist/src/v0_9/*/*/*.test.js) instead of simply pointing to the dist directory or using quoted ** globs.
• Linting Fix: Resolved @typescript-eslint/no-unused-vars linting errors in renderers/web_core/src/v0_9/catalog/types.test.ts by asserting the unused type-level variables at runtime via assert.strictEqual().

Rationale

• The missing runs-on property in the lint job caused GitHub Actions to throw a parsing error, marking the entire web_build_and_test.yml workflow as invalid and preventing both tests and linting from running at all.
• Node's native test runner (node --test) can fail with module resolution (MODULE_NOT_FOUND) errors when pointed directly at a compiled directory like dist in a "type": "module" project. Node 20 environments (like the one used in GitHub Actions) do not internally expand quoted ** globbing without shell assistance. Switching to explicit wildcard globs allows the files to be correctly resolved by the runner across local and CI environments.
• The type-level assertions in the test files triggered the linter's unused variable detection, causing the npm run lint CI job to fail. Adding assertions removes the violations.

Testing/Running Instructions

1. Pull down this branch locally.
2. Navigate to the renderers/web_core directory: cd renderers/web_core
3. Run the tests: npm run test (should pass successfully and find all tests).
4. Run the coverage checks: npm run test:coverage
5. Run linting: npm run lint (should pass with no errors).
6. Review the Actions tab in GitHub to ensure the Web core workflow now successfully parses, triggers, and completes both the build-and-test and lint jobs.

Pre-launch Checklist

• I read the [Contributors Guide].
• My code changes (if any) have tests.

[gemini-code-assist]

Code Review

This pull request updates the test execution commands in package.json to target specific subdirectories and modifies types.test.ts to replace type-level variable assignments with runtime assertions to satisfy linting requirements. Feedback indicates that the shell glob expansion in the package scripts is not cross-platform and suggests using a globbing utility. Additionally, for type-level tests, it is recommended to use ESLint disable comments instead of adding unnecessary runtime assertions.

[gemini-code-assist]

This change relies on shell glob expansion to find test files, which is not cross-platform. While this will work on Unix-like shells (Linux, macOS), it will likely fail on Windows cmd.exe because it does not expand wildcard (*) characters in command arguments. The node executable would receive the unexpanded string literal.

Additionally, the test paths are hardcoded and duplicated in the test:coverage script (line 67), creating a maintenance burden.

For a robust and cross-platform solution, consider using a helper package like glob to programmatically find the test files and pass them to node --test. This would ensure the test command works consistently across all developer environments.

[ditman]

Wow, weren't these tests working before?

[jacobsimionato]

Nup! I can't believe it either!

Yes, let's try the glob approach - that sounds better.

[ava-cassiopeia]

hmmm...I have no trouble running all the tests by simply running

node --test dist

locally, no globbing patterns required. Do we need to do this? dist seems like a sufficient target and should work on windows.

[gemini-code-assist]

While adding an assertion is a valid way to address the no-unused-vars linting error, it adds runtime code that always passes and doesn't contribute to the test logic itself. The primary check here is performed at compile-time by TypeScript, making the variable intentionally unused at runtime.

An alternative and often clearer approach for such type-level tests is to use an ESLint disable comment. This explicitly communicates the intent without adding boilerplate runtime code. This same feedback applies to the typesMatchExact variable on line 134.

Consider this alternative:

Suggested change

	const inferredIsAny: IsAny<InferredType> = false;
	assert.strictEqual(inferredIsAny, false);
	// eslint-disable-next-line @typescript-eslint/no-unused-vars
	const inferredIsAny: IsAny<InferredType> = false;

[ditman]

There's no need for these assertions, if the inference was broken, assigning to "false" on line 122 wouldn't compile, I think!

[jacobsimionato]

Ahhh I see, that makes sense. Let's add the eslint disable comment instead.

[ditman]

I think you can revert the changes to types.test.ts (?)

[ditman]

There's no need for these assertions, if the inference was broken, assigning to "false" on line 122 wouldn't compile, I think!

[ditman]

Wow, weren't these tests working before?

[ava-cassiopeia]

hmmm...I have no trouble running all the tests by simply running

node --test dist

locally, no globbing patterns required. Do we need to do this? dist seems like a sufficient target and should work on windows.

[ava-cassiopeia]

I suppose I would also add that if we're worried about windows compilation, can we ask for a windows machine in a job? Most of us at Google are using POSIX-compliant systems (gLinux or macOS), so I don't think we're going to catch regressions like that on our own very well.