Use node package resolution for bundle sources, enable Zoe in cosmic-swingset to use prebundled zcf

[FUDCo]

No description provided.

[warner]

If this is given ./vats/vat-timerWrapper.js, will it return the absolute path of SwingSet/src/vats/vat-timerWrapper.js instead of something near the config file? That seems surprising. I'm inclined to only call require.resolve here when specPath doesn't start with ./ or ../.

[michaelfig]

Please investigate using:

function resolveSpecFromConfig(dirname, specPath) {
 // This is only resolved by Node's algorithm relative to dirname.
 return require.resolve(specPath, { paths: [dirname] });
}

This trick works for all absolute and relative paths, even outside of Node.js packages. No need to be clever when Node.js already does the work for you.

[michaelfig]

Please see my top-level comment on this PR.

[FUDCo]

Giving require.resolve a path eliminates the need to inspect the path to see if it's relative to './' or '../' and still takes care of the case that Brian flagged, but by itself it's not sufficient. It will produce a MODULE_NOT_FOUND error for a bare filename (e.g., foo.js) or a path beginning with a directory name (e.g., subdir/foo.js), so you still need to do a path.resolve to handle those cases properly.

[michaelfig]

LGTM!

[michaelfig]

Okay, now I see what you're going for. I, personally, would prefer that a specifier is the exact same resolution semantics as for modules (i.e. use ./foo.js if you mean foo.js in the current directory). If you agree with that sentiment, you could print a deprecation warning if the path.resolve is hit.

Up to you, though. I can see the convenience of being able to resolve bare specifiers relative to dirname, even though it gives me the willies. 😄

[michaelfig]

Would it maybe be better to try path.resolve() first on bare specifiers, then punt to require.resolve for everything else or if the resolve doesn't result in a file? That would eliminate the surprise when you do "lodash" but you meant "./lodash/index.js".

[FUDCo]

Keep in mind that these paths appear inside config files and have a different use pattern from imports. With imports, it's common that a large fraction of the stuff you are referring to comes from someplace else. In config files, non-local references are the exception; you would never reference "./lodash/index.js". Not having to stick a redundant ./ in front of almost literally everything improves readability quite a bit.