Currently, we run tests for each package against a just-in-time, in-memory compiled version of that package, using the TypeScript configuration defined in this repo (thanks to ts-jest). We also have a way of statically analyzing package.json via the "Are the Types Wrong?" tool, and running this would give us some information on better practices we ought to follow when it comes to dual builds.
However, we have no idea whether these builds actually work in various scenarios. What we are missing is a way to run tests against different versions of the compiled JavaScript, simulating various kinds of projects.
Acceptance Criteria
We are able to detect and prevent the error with default exports that David Murdoch mentioned in this Slack message (also see this one)
We are able to detect other kinds of errors that may only pop up in a TypeScript project with different settings and/or in ESM mode or in CommonJS mode and/or using different build tools
Whatever tests we come up with, it is easy to copy them to other repos so that we can set them up with smoke tests fast
desi
commented
3 months ago
Recently, the extension team has encountered issues with dependencies in
corepackages which ship with a default export. This causes the ESM and CJS builds to act differently, leading to an extremely frustrating experience.Currently, we run tests for each package against a just-in-time, in-memory compiled version of that package, using the TypeScript configuration defined in this repo (thanks to
ts-jest). We also have a way of statically analyzingpackage.jsonvia the "Are the Types Wrong?" tool, and running this would give us some information on better practices we ought to follow when it comes to dual builds.However, we have no idea whether these builds actually work in various scenarios. What we are missing is a way to run tests against different versions of the compiled JavaScript, simulating various kinds of projects.
Acceptance Criteria