consider adding user-like code that can be type checked

[brendankenny]

It could held catch issues like #351 and #358 at build time if there was more code using the various entry points like a user.

Two ideas so it's not just extra files to maintain:

• currently the tests have inlined scripts (e.g. onCLS). These could be moved to separate script files that are type checked (or could use whatever fancy thing you need to extract and typecheck ts code in njk files). Extra work: maybe need to use more properties on the returned objects than just destructure and jsonify to make sure e.g. they're string | undefined and not unknown.
• make an examples/ directory with some of the examples from the readme moved and/or expanded there and type check the code in there. Could be useful in general, especially with the readme already quite lengthy and many visitors wanting easy copy/pastes to get started.

[philipwalton]

In general, I think this is a good idea. In addition to the cases you've outlined, there have also been cases in the past where people were getting errors from import/require()-ing modules from web-vitals for SSR in a Node.js context, and I've updated the library to fix those issues and not error when imported in Node.js ... but we have no tests to ensure we don't regress there.

My sense is we don't want to change how the existing e2e tests are run; instead we can create a new set of tests that run in node or on the command line and call tsc or whatever and assert they complete without error.

WDYT?

[tunetheweb]

Agreed. We added some unit tests in #323 btw, but not very comprehensive yet.