Skip to content

build(internal): add test compilation check to package builds#5336

Merged
svozza merged 4 commits into
mainfrom
build/test-compilation-check-5073
Jun 12, 2026
Merged

build(internal): add test compilation check to package builds#5336
svozza merged 4 commits into
mainfrom
build/test-compilation-check-5073

Conversation

@dreamorosi

@dreamorosi dreamorosi commented Jun 12, 2026

Copy link
Copy Markdown
Contributor

Summary

Changes

Package builds only compile source code under src/; test files under tests/ were never type-checked, so type errors in tests could go unnoticed until runtime. This PR adds a dedicated test type-checking step so those errors are caught in CI.

  • build:tests script added to each package (tsc --noEmit -p tests/tsconfig.json).
  • build:tests is intentionally NOT wired into the regular build — day-to-day builds stay fast and never emit test files into the published bundle.
  • CI runs the type-check as a dedicated step (Type check tests) in the code-quality matrix job, after dependencies are installed and the whole workspace is built (so every package's lib/ exists for cross-package import resolution).
  • Created the missing tests/tsconfig.json for jmespath (the only package without one).
  • Fixed pre-existing test type errors surfaced by the new check:
    • commonsdeepMerge.property.test.ts (invalid depthSize on fc.array constraints → size) and deepMerge.test.ts (typed the result of deepMerge({}, source)).
    • metricsbasicFeatures.decorator.test.functionCode.ts (made the decorated handler async so it satisfies HandlerMethodDecorator).

Notes for reviewers

  • The original proposal suggested wiring build:tests into build in parallel (& npm run build:tests). That is unsafe here: the test type-check resolves cross-package imports against each dependency's built lib/, but the workspace build order builds some dependencies (e.g. testing) after their consumers, and the parallel & also races a package's own emit build. Running it as a separate CI step after the full build avoids the race entirely.
  • The proposal also suggested removing ../src/**/* from tests/tsconfig.json. That cannot be done here: the configs inherit composite: true, which makes TypeScript enforce TS6307 ("Projects must list all files or use an include pattern"). The source glob is kept (including in the new jmespath file).
  • Maintainer caveat (tests must not end up in the published npm bundle) holds: the emitting builds use rootDir: ./src + include: ["./src/**/*"], build:tests uses --noEmit, and it is not part of the regular build. Verified no test files land in any lib/ output.
  • Verified locally: emit-only npm run build passes, and npm run build:tests -w <pkg> passes for every package after a full build.

Issue number: closes #5073


By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

Type-check test files during the build via a new `build:tests` script
(`tsc --noEmit -p tests/tsconfig.json`) that runs in parallel with the
ESM and CJS builds. This catches type errors in test files that were
previously only surfaced at runtime.

- Add `build:tests` to every package and wire it into `build`
- Create the missing `tests/tsconfig.json` for jmespath
- Fix pre-existing test type errors in commons and metrics

Note: the `tests/tsconfig.json` files keep including `../src/**/*`
because the configs inherit `composite: true`, which requires every
file in the program to be listed (TS6307).

closes #5073
Running `build:tests` in parallel within each package's `build` was
unsafe: the test type-check resolves cross-package imports against each
dependency's built `lib/`, but the workspace build order builds some
dependencies (e.g. `testing`) after their consumers, and the parallel
`&` also races a package's own emit build.

Instead, keep the per-package `build:tests` script out of the regular
`build` (so day-to-day builds stay fast and don't emit tests) and run
it as a dedicated `Type check tests` step in the code-quality CI job,
after dependencies have been installed and the whole workspace built.
@powertools-for-aws-oss-automation powertools-for-aws-oss-automation Bot added size/S PR between 10-29 LOC and removed size/M PR between 30-99 LOC labels Jun 12, 2026
@dreamorosi dreamorosi requested a review from svozza June 12, 2026 10:45
@svozza

svozza commented Jun 12, 2026

Copy link
Copy Markdown
Contributor

Can we add the check to the pre-commit hook so we don't have to wait until the CI fails if we forget to run it locally?

@powertools-for-aws-oss-automation powertools-for-aws-oss-automation Bot added size/M PR between 30-99 LOC and removed size/S PR between 10-29 LOC labels Jun 12, 2026
@dreamorosi

Copy link
Copy Markdown
Contributor Author

Can we add the check to the pre-commit hook so we don't have to wait until the CI fails if we forget to run it locally?

Good point - added, but to pre-push in line with when we run the other tests.

@powertools-for-aws-oss-automation powertools-for-aws-oss-automation Bot added size/M PR between 30-99 LOC and removed size/M PR between 30-99 LOC labels Jun 12, 2026
@sonarqubecloud

Copy link
Copy Markdown

@svozza svozza merged commit ca88c0b into main Jun 12, 2026
40 checks passed
@svozza svozza deleted the build/test-compilation-check-5073 branch June 12, 2026 16:09
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

size/M PR between 30-99 LOC

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Maintenance: Add test compilation check to package builds

2 participants