dom-testing-library: Some dependencies don't support ES modules

I’m having a hard time understanding why this is an issue on our side? So far the guarantee was always that you can import CJS from ESM. So everything should be working without any work on our side.

@eps1lon this is not actually true. Node cannot guarantee safe importing. I am trying to create a loader that will allow Node to understand module field, and I was quite successful with it. However, Node doesn’t allow importing named exports, if it didn’t find them (they were defined not in a global namespace, or dynamically). Currently, I am getting this error from this package:

SyntaxError: Named export 'compressToEncodedURIComponent' not found. The requested module 'lz-string' is a CommonJS module, which may not support all module.exports as named exports.
CommonJS modules can always be imported via the default export, for example using:

import pkg from 'lz-string';
const { compressToEncodedURIComponent } = pkg;

I guess the solution would be to use import { compressToEncodedURIComponent } = require('lz-string'). That way transpiler can understand that you use CJS package, and will transform it into:

const require = createRequire(import.meta.url)
const { compressToEncodedURIComponent } = require('lz-string')

Could you file an issue against NodeJS in that case please? Their documentation clearly states you can import CommonJS from ES modules:

An import statement can reference an ES module or a CommonJS module.

It doesn’t contradict documentation. You can import CJS module, but you might not be able to use named exports, if they are not statically analysable:

Live binding updates or new exports added to module.exports are not detected for these named exports.

The detection of named exports is based on common syntax patterns but does not always correctly detect named exports. In these cases, using the default import form described above can be a better option.

Named exports detection covers many common export patterns, reexport patterns and build tool and transpiler outputs. See cjs-module-lexer for the exact semantics implemented.

– https://nodejs.org/api/esm.html#commonjs-namespaces

If it cannot detect a named export, it will throw an error that I described.

I think in this specific case it has more to do with the way we import

Yes, technically lz-string cannot be exported as { namedExport }, since its exports are not statically analysable (it just puts an object on module.exports - as you can see from the quote above these bindings are not detectable).

I made a small reproduction for you, using stackblitz: https://stackblitz.com/edit/node-fpxnof?file=index.mjs

There are several ways to fix this:

• If you use typescript, you can use import name = require('path'), which is a way to tell typescript to use require here
• You can also use what Node recommends in its error: import defaultLz from 'lz-string'; const { namedExport } = defaultLz

That’s similar to what I’m getting. I just got back to my laptop and checked, and I am using esbuild which should get you past that error (I think).

I pushed up a couple versions of my demo repo:

• Snowpack using remote sources (main branch): https://github.com/jimsimon/wtr-dtl
• Snowpack using local sources (snowpack-local branch): https://github.com/jimsimon/wtr-dtl/tree/snowpack-local
• WTR using it’s built in Web Dev Server + ESBuild (wtr-using-wds branch): https://github.com/jimsimon/wtr-dtl/tree/wtr-using-wds

Hopefully these help. The last link is the one I’d most like to see working and is what spawned this ticket and convo. The Snowpack stuff was an attempt at working around the issue.

Note: The test won’t actually pass if you get it to run. That’s a different issue/concern regarding being able to pass ShadowRoot to queries. I’m hoping we can address that in a different issue/ticket if we can get this one resolved.

FYI aria-query is a dependency of getByRole anyways, so pulling out the queries package will not fix the module format issue for this use case

I’m seeing two related issues here, so I’ll split up my response:

Supporting different frameworks

As far as I’m aware, while we primarily focus on Jest support, we still want to support other test frameworks. Testing Library shouldn’t necessarily require Jest, it’s just a convenient option because of its simple extensible APIs and built in JSDOM support, and it’s already popular in the React community.

That being said, I have seen some bugs in some of our packages caused by us assuming a JSDOM environment in Jest, which can cause issues with supporting a real DOM, such as in web-test-runner. I’m assuming that your issue is either related to DOM support or ES module support. Either way, I would appreciate it if you could post an example (preferably one we could run locally) showcasing your specific issues with using DOM Testing Library in web-test-runner.

Using only queries

Because DOM Testing Library doesn’t rely on any specific web framework, it works with plain DOM Nodes, so its queries should already be useful in isolation. If you don’t want the entire package namespace imported, you have three options:

1. Import screen to use any query on the entire document: import { screen } from "@testing-library/dom"
2. Import specific queries to use them on any element: import { getByText } from "@testing-library/dom"
3. Import queries to use any query on any element: import { queries } from "@testing-library/dom"

From a packaging optimization perspective, I’m not sure how well we support tree shaking, which would let build tools remove other parts of the library that queries don’t depend on. If you have a situation where you need to use Testing Library in production but your bundle is too build, I can try to help you look into that if you can post more information, such as the results of running webpack bundle analyzer.

From a package maintenance perspective, separating out our queries into a separate package would require additional infrastructure and manual package dependency bumps (which is a bit trickier to keep track of since we’re not using monorepos/workspaces). DOM Testing Library doesn’t have too many dependencies, and as long as tree shaking is working properly they can be removed when they’re not used anyway. Additionally, I think it’s worth noting that our framework specific packages like React Testing Library wrap other DOM Testing Library APIs such as waitFor, so just importing the queries wouldn’t be enough.

Example

Let’s say you were writing a debugging tool that prints a DOM Node in the console after asking the user for its text content, so you don’t care about our other testing utilities such as waitFor, Jest DOM, or React Testing Library. You could import only the queries you want to use and use the DOM Nodes they return.

import { screen } from "@testing-library/dom";

const text = prompt("Type in the text of a Node to get");

if (text) {
  const node = screen.getByText(text);
  console.log(node);
} else {
  console.log("Node not found");
}