cjs-module-analyzer doesn't find requires if they're not top-level

const { requires } = analyzeCommonJS(`
  mime(require('./types/standard'), require('./types/other'));
  `);

requires is an empty array.

Works fine if require call statements are not arguments to a function

Attempted fix:
https://github.com/endojs/endo/commit/2703569cd663040c7cb1f3efb7b786ed1d6249d6

The change causes any require() call to produce a requires entry, which may lead to

 Cannot find file for internal module "./niematakiegonumeru" (with candidates "./niematakiegonumeru", "./niematakiegonumeru.js", "./niematakiegonumeru/index.js") in package file:///...

Which in turn could be solved with a change here: https://github.com/endojs/endo/blob/a7b42ae2388b232f7daa099495ba11f385010fd1/packages/compartment-mapper/src/import-hook.js#L160-L175 Instead of erroring out, returning a dummy static module record that throws the error when execute is called could work. That way it’d emulate cjs more closely and not fail if the require reference was not the actual require.

[shrinktofit]

#1090 does not capture the following require:

import { analyzeCommonJS } from '@endo/cjs-module-analyzer';
const info = analyzeCommonJS(`
(function(){
    require('crypto');
})();
`);
console.log(JSON.stringify(info, undefined, 2)); // All empty arrays

[naugtur]

I added postponing errors to import-hook.

PR: https://github.com/endojs/endo/pull/1090

---

I started looking into decoupling esm and cjs specific logic.

Parsing needs to differ between esm and cjs, so it’s provided as an argument. Meanwhile figuring out local paths is following the cjs logic, as you said.

All the differences could come in from mapParsers (with a name change ofc) where instead of a parse we’d get { parse, read, errorReporter } Instead of generating candidates and looping over them, I suggest we supply a wrapped read that finds the one file and returns it, which in turn allows collapsing read and parse into one

mapParsers is aware of cjs already and all that awareness could potentially be encapsulated there. All references to actual implementation come from the very top, via parserForLanguage which we could rename slightly to something like behaviorsForLanguage

The only hole in this idea is if module specifier is not starting with . and parser may not need to be provided - there’s no way to decide on the error behavior other than forcing the caller to pass, but AFAICT there’s only one place where importHookMaker is ever called and that guarantees parser to come in.

Here’s a messy start of the refactoring as a base for discussing if the shape of import-hook.js and parse-* seems better that way https://github.com/endojs/endo/commit/b413631c1eb3ba51ecd8fe556c8158200a287272