feat: Allow passing of include or exclude list via module.register()

[timfish]

This PR adds the ability to pass an array of modules or URLs to include or exclude from wrapping via the data property passed as the third argument of module.register().

Since import-in-the-middle has issues that we don't know how to solve, it makes sense to allow a way to work around these issues so it can still be used.

[vchirikov]

@timfish previously I patch the lib and use url.startsWith('node:') to include everything from node: only, I think it's very useful to allow pattern/regex entries in include/exclude, what do you think?

[timfish]

Hey @vchirikov. Yep, a good idea.

PRs are welcome. Just keep it non-breaking, add some tests and it will likely get merged and released quickly!

[FabianFrank]

Really appreciate people trying to work through this for real and make the fix a proper library options. I tried using the exclude option to avoid wrapping the openai package like so:

register("import-in-the-middle/hook.mjs", import.meta.url, {
  parentURL: import.meta.url,
  data: {
    exclude: [
      // openai shim breaks with import in the middle, see https://github.com/openai/openai-node/issues/903
      "openai",
    ],
  },
})

That said, it does not seem to be enough. Only the openai import itself, i.e. the top level export of openai, is skipped by ITIM since the exclude is an exact match. I have to add code like for example

    if (parentURL.includes("/openai/")) {
      console.log("skip openai", parentURL, specifier)
      return result
    }

to resolve in hook.js to prevent wrapping all other files in openai and thus

Does someone actually have a working example where openai breaks due to ITIM and is fixed by setting this option, but all other modules still get intercepted?

[timfish]

There has already been a request to allow regular expressions for exclude/include which would help here. I'll probably submit a PR for this over the weekend.

Until then, you could use include and only list the libraries that you're instrumenting.

I think #146 is the long term solution for most.