Problem
The current JS smoke tests provide limited confidence for validating JS emitter changes.
Because of the limited coverage and unchanged typespec, it often fail to catch real‑world regressions introduced by emitter updates.
And considering its large size, we don't plan to move them as part the emitter movement.
Proposal
Introduce a regenerate‑all‑SDK validation pipeline for the JS emitter as a replacement for the current JS smoke tests.
Key aspects of the proposal:
- Regenerate a selected set of representative JS SDK libraries using the JS emitter
For efficiency, it is not suggested to regenerate all SDKs; instead choose a small but representative set (e.g. data plane + management plane, different API shapes).
AI + Manual effort to validate regeneration results
- Successful code generation
- Clean build / lint / basic test pass
- Detect breaking change or emitter‑level regressions early
Run this pipeline on a scheduled basis (e.g. weekly)
Problem
The current JS smoke tests provide limited confidence for validating JS emitter changes.
Because of the limited coverage and unchanged typespec, it often fail to catch real‑world regressions introduced by emitter updates.
And considering its large size, we don't plan to move them as part the emitter movement.
Proposal
Introduce a regenerate‑all‑SDK validation pipeline for the JS emitter as a replacement for the current JS smoke tests.
Key aspects of the proposal:
For efficiency, it is not suggested to regenerate all SDKs; instead choose a small but representative set (e.g. data plane + management plane, different API shapes).
AI + Manual effort to validate regeneration results
Run this pipeline on a scheduled basis (e.g. weekly)