Packaging this library in a bundle to run using Cloudwatch synthetics.

[azaharakis]

I'm currently looking to use this library to wrap cloudwatch synthetics use of puppeteer. To package the necessary code i'm using webpack to produce a bundle which will be provided to Cloudwatch Synthetics. The issue that i'm facing is that this underlying dependency: https://github.com/testing-library/pptr-testing-library/blob/860106be873fa6830c49e529ec1a0b2a65f9bbbd/lib/index.ts#L8

is being loaded via readFileSync which webpack obviously does not pull in as part of its bundle. My question would be why is this the case? And would you have any recommendations as to packaging this library for use with in a lambda?

[chrbala]

I also had this problem. To unblock myself, copied the entry point in the library as shown below and set up Webpack to load the file with raw-loader.

import {ElementHandle, EvaluateFn, JSHandle, Page} from 'puppeteer';
import waitForExpect from 'wait-for-expect';

import {
  IConfigureOptions,
  IQueryUtils,
  IScopedQueryUtils,
} from 'pptr-testing-library/dist/typedefs';

import domLibraryAsString from 'raw-loader!pptr-testing-library/dom-testing-library.js';

But this library should handle this use case. I see a few ways to fix this:

1. Allow the consuming code to pass the domLibraryAsString value if this default readFileSync does not work. It could load it in whatever way needed, such as with raw-loader. This is a bit of a leaky abstraction, but it is very explicit. It also gives consumers full control over which version of @testing-library/dom to load.
2. Build @testing-library/dom into pptr-testing-library. This would change @testing-library/dom from a dependency into a bundledDependency, meaning that consuming code does not have control over the minor or patch versions of @testing-library/dom. This might be fine, but it's worth keeping in mind.
3. Import the file with raw-loader, and allow consuming code to configure webpack to make this work. This is a very leaky abstraction and requires consumers to use webpack. This is also complicated by the fact that pptr-testing-library uses esbuild. This seems like a bad option.

@patrickhulce can you give some guidance here?

[patrickhulce]

Thanks for filing! Good questions.

1. This is possible to do without modification to pptr-testing-library using tools like memfs and brfs. Might be useful to understand the workarounds here if you're targeting generic node usage in a bundled environment 👍
2. I'm also open to shipping either a bundled version of pptr-testing-library or exposing domLibraryAsString in a non-breaking way if there's a contributor interested in making it happen :)

[msrose]

A note of clarification for anyone else coming along this problem: The dom-testing-library.js source code should be treated as a string, NOT a JS module, since it needs to be passed exactly as-is to puppeteer by pptr-testing-library: https://github.com/testing-library/pptr-testing-library/blob/860106be873fa6830c49e529ec1a0b2a65f9bbbd/lib/index.ts#L47

So make sure to either tell webpack not to run any sort of transformation on dom-testing-library.js (the raw-loader solution suggested above or similar is one way to do it), or just don't pass dom-testing-library.js through webpack at all -- copying dom-testing-library.js to the directory above your bundled code works fine (since the pptr-testing-library source does a file read on '../dom-testing-library.js').

I think this is the least mind-bending way to get the bundling working, but it does depend on the file path specified in the pptr-testing-library implementation, so if you go this route I'd recommend locking the version of pptr-testing-library in your package.json.