The problem

This works:

Hook(['ioredis'], (exports, name, baseDir) => {
  console.log('HIT: name=%s', name)  // matched, name=="ioredis"
})
await import('ioredis')

but IITM does not match when the module "main" file is deep-imported:

Hook(['ioredis'], (exports, name, baseDir) => {
  console.log('HIT: name=%s', name)  // Note: IITM does not match here
})
await import('ioredis/built/index.js')  // deep import of the module "main" file

This does work with RITM.

RITM does extra work (using require.resolve(moduleName)) to realize that the loaded filename/URL (e.g. "/Users/trentm/my-app/node_modules/ioredis/built/index.js" in this case) file is the package "main" file, and then returns the module name rather than the internal file path.

Fixing it?

I don't know how IITM could fix this.

RITM is using require.resolve(modName).
For IITM to do the equivalent, it would have to use import.meta.resolve(modName). However, IIUC, that can only be used in an ESM module and all the IITM code here is CommonJS at this point.

There is an argument to be made that perhaps this need not be changed to match RITM, because:

• It is nice that IITM isn't doing this extra require.resolve(...)-type work for many loads (RITM could likely cache better).
• This should be rare, right? Not sure. Brian's early commit changing the API to match RITM included an assertion that Hook(['c8']) does not match import 'c8/index.js', which is interesting.
• As mentioned in "Option 2" of with internals: true the name returned for the imported specifier is the implementation file, different from RITM #238 I think observability tools moving to specifying the exact implementation files to monkey-patch, rather than entry-points (including the module name) would be more robust. I.e. prefer hooking ioredis/built/index.js over hooking ioredis.

Granted that means changing instrumentations... and coping with the IITM/RITM difference, or perhaps getting RITM to add that 4th modPath arg I mentioned in #238

Thoughts?