Recommendation for build testing

[make-github-pseudonymous-again]

I have AVA setup to test the source files transpiled on-the-fly via Babel. For a long time I used Babel to produce package release builds. Since the same tool/config was used for testing and building I was not too worried that something would differ between temporary testing builds and release builds. Hence I did not bother to test release builds assuming everything would work without problem. I depend on some of these released packages in some real projects and never had a problem so far.

Now, I started to use microbundle instead of babel to produce release builds. Here, I am less confident that everything will go smoothly. I already noticed some discrepancies, but nothing too worrying so far (EDIT: here is a worrying one). Just to be on the safe side, how would one approach testing both the sources and the build output with ava. Currently, my test code imports the sources through some relative path (e.g. ../../src/index.js) hardcoded inside each test file. I thought about passing command line arguments to ava, then using some dynamic require require(process.argv[2]), but I am not sure this is such a good idea. Is there any standard solution to this problem? Is this a real problem?

[novemberborn]

If you can import individual classes / functions / components from your release build then you can write the tests against those.

If that's not an option, perhaps you can do some integration tests against the release build, and hope for the best?

[make-github-pseudonymous-again]

If you can import individual classes / functions / components from your release build then you can write the tests against those.

I want to avoid running microbundle everytime I run the tests in development.

If that's not an option, perhaps you can do some integration tests against the release build, and hope for the best?

Ideally I would like to run the same tests on the source ../../src/index.js with on-the-fly babel transpilation of required files and on the build artifacts, which may be more than one (e.g. ../../dist/index.js, ../../dist/index.umd.js, ../../dist/index.module.js, ../../dist/index.modern.js, ...) without on-the-fly babel transpilation of required files (but still babel transpilation for test files). Test coverage only needs to be computed for the sources.

I understand that this will only make sense for builds that can be executed natively by whatever CI hosting I am using. Maybe keeping on-the-fly transpilation for all artifacts with @babel/preset-env and { 'targets': 'current node' } would make it work.

[make-github-pseudonymous-again]

Could we exploit import maps?

[novemberborn]

That's up to you — AVA runs within Node.js so if your tests use import maps I imagine Node.js will pick that up.

[make-github-pseudonymous-again]

I have a WIP example here: async-abstraction/tape#205

[make-github-pseudonymous-again]

I am hitting one limitation with another package. One of the built bundle is using Object.defineProperty(exports, ...) to export named exports. Since these cannot be found by static analysis, they are not accessible through named imports. Any idea on how to circumvent this limitation? I tried to leverage importInterop but this causes the named exports to be undefined for some reason. I also tried to transpile ava test file on-the-fly to cjs but then node complains that the package is of type module and we are using require in a .js file...