New transformTestFile option to interface with bundlers

[Prinzhorn]

I'm using AVA for unit tests and it has worked great so far. Now I wanted to add integration tests, but AVA (or Node.js rather) chokes on .sql imports. I import .sql migration files using the esbuild text loader. This way I end up with a single bundle and faster startup time (Electron).

I'm sure there are multiple ways to work my way around this, e.g. having my tests as *.build.test.js, ignore them in AVA config and have an esbuild process output bundled .test.js files without the build part, which AVA will pick up. But that doesn't sound fun. What does sound fun would be something like this:

export default {
  transformTestFile: async (file) => {
    let transformed = await esbuildMagic(file);
    return transformed;
  },
};

I assume other bundlers could use this interface in a similar fashion and transforms could be provided for ts and whatnot.

import { transform } from 'my-svelte/vue/react/ts-transform';

export default {
  transformTestFile: transform
};

From what I can tell right now there is no unified way to do things. And I'm definitely not going to try to integrate babel to do something that esbuild is already doing for my actual code. To me this looks cleaner than any of ts-node, babel, require-hooks, --experimental-loader and whatnot.

[novemberborn]

@ava/typescript uses an extensible protocol for hooking into test file selection, pre-compilation and loading. It's just not generically available, which is a change we can make.

Note though that this only impacts the test files themselves, which does suit your use case. For other approaches loader hooks are more appropriate.

[Prinzhorn]

Sounds good to me. If you could abstract this into some sort of generic @ava/transform (which @ava/typescript uses/extends) I could probably use that to hook into the appropriate life cycle parts? Before polishing this you could point me to some duct taped version that I could evaluate with my setup. I'd be happy to test that and give feedback if it works or if we are missing something (e.g. I've declared some modules as external because they cannot be bundled, but that shouldn't be an issue, since the transpiled test file can still access the same node_modules)

[Prinzhorn]

One more thing I was curious and you can probably answer: from what I can tell @ava/typescript actually creates compiled files in a different folder. Would it be possible to pass data: or eval: true to each Worker? Because with esbuild I don't see a reason to write the bundled test files to the file system at all, I can use write: false and get the string back. Did you ever experiment with that in AVA? Would the tests even work when the worker uses a string of JavaScript? Or does that break some assumptions AVA makes?

[novemberborn]

There's already a fairly generic protocol:

• https://github.com/avajs/ava/blob/6f8e30c94626238a5b26deadac319089fa43d333/lib/provider-manager.js

• ava/lib/globs.js

  Lines 69 to 71 in 6f8e30c

  	for (const {main} of providers) {
  	({filePatterns, ignoredByWatcherPatterns} = main.updateGlobs({filePatterns, ignoredByWatcherPatterns}));
  	}

• ava/lib/globs.js

  Line 186 in 6f8e30c

  const providerExtensions = new Set(providers.flatMap(({main}) => main.extensions));

• ava/lib/api.js

  Lines 241 to 247 in 6f8e30c

  	const providerStates = [];
  	await Promise.all(providers.map(async ({type, main}) => {
  	const state = await main.compile({cacheDir: this._createCacheDir(), files: testFiles});
  	if (state !== null) {
  	providerStates.push({type, state});
  	}
  	}));

• ava/lib/worker/base.js

  Lines 126 to 139 in 6f8e30c

  	const providers = [];
  	await Promise.all(providerStates.map(async ({type, state}) => {
  	if (type === 'typescript') {
  	const provider = await providerManager.typescript(projectDir);
  	providers.push(provider.worker({extensionsToLoadAsModules, state}));
  	}
  	}));
  	const require = createRequire(import.meta.url);
  	const load = async ref => {
  	for (const provider of providers) {
  	if (provider.canLoad(ref)) {
  	return provider.load(ref, {requireFn: require});
  	}

It would only take a few tweaks to make that fully extensible (without requiring the provider to be recognized by AVA).

Regarding the loading, AVA still very much wants to require or import, but the provider can control the URL that is imported so that could be a data URL. See the worker/base file above.

[Prinzhorn]

Thanks a lot, I'll look into this in the future. It's not a priority right now but I'll come back to it when I figured some other stuff out.