Support installed npm modules and relative require

[jclem]

This adds support for the following:

• Requiring modules by a path relative to the working directory require('./foo')
• Requiring npm modules installed in the working directory require('lodash')

This is accomplished by wrapping the require passed to the script in a proxy.

• When the script calls require with a path that starts with '.', we transform that module ID to the result of path.join(process.cwd(), moduleID) and then require the absolute path, instead.
• When a script calls require for some non-relative path and an error is thrown, we catch that error and try again, this time adding process.cwd() to the list of paths searched-through.

Thanks to @joshmgross and @wraithgar for doing the real work here 😄

[github-actions]

Hello from actions/github-script! (3110e8d)

[JamesMGreene]

Question: Have you tried adding node_modules to the path here? I think that should work, while also preventing accidental resolutions to local modules, i.e. require('hi') => require(process.cwd() + '/hi.js')? 🤔

Suggested change

	paths: eval('module').paths.concat(process.cwd())
	paths: eval('module').paths.concat(path.resolve(process.cwd(), 'node_modules'))

[jclem]

I may have mis-tested, but when I tested this, using this method did not result in the ability to require('foo') and have it resolve to ./foo.js. Surprisingly, module.paths.push(process.cwd()) did have this effect, but not this method.

[JamesMGreene]

Concern: I feel like the order here of the try vs. catch block is backwards.

When using a require('lodash') from my github-script block now, that may end up requiring an incompatible version of the module if it exists as a dependency somewhere "near" to where the github-script code is executed rather than relying on the CWD's package.json file. 😬

[jclem]

Ah this is a good point. Instead, we should perhaps remove this entire try/catch construct and just do this:

const modulePath = target.resolve.apply(thisArg, [
  moduleID,
  {
    // Webpack does not have an escape hatch for getting the actual
    // module, other than `eval`.
    paths: [process.cwd(), ...eval('module').paths]
  }
])

return target.apply(thisArg, [modulePath])

[jclem]

Fixing in #136

[JamesMGreene]

Thanks!