FazBrowse GitHub Viewer | Trending |
URL:
| Home
Tools: [Download Repo ZIP]   [Original HTTPS Page]

Support installed npm modules and relative require by jclem · Pull Request #135 · actions/github-script · GitHub

Support installed npm modules and relative require - #135

Merged
jclem merged 25 commits into
mainfrom
wrap-require
Apr 21, 2021
Merged

Support installed npm modules and relative require#135
jclem merged 25 commits into
mainfrom
wrap-require

Conversation

jclem commented Apr 21, 2021
edited
Loading

Copy link
Copy Markdown
Contributor

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 Bot commented Apr 21, 2021
edited
Loading

Copy link
Copy Markdown

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

jclem marked this pull request as ready for review April 21, 2021 20:38
jclem requested a review from a team April 21, 2021 20:38
jclem changed the title Wrap require to support relative requires Support installed npm modules and relative require Apr 21, 2021
Comment thread src/wrap-require.ts Outdated
jclem merged commit 95fb649 into main Apr 21, 2021
jclem deleted the wrap-require branch April 21, 2021 21:50
Comment thread src/wrap-require.ts
{
// Webpack does not have an escape hatch for getting the actual
// module, other than `eval`.
paths: eval('module').paths.concat(process.cwd())

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Choose a reason Spam Abuse Off Topic Outdated Duplicate Resolved Low Quality

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 Apr 21, 2021
edited
Loading

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Choose a reason Spam Abuse Off Topic Outdated Duplicate Resolved Low Quality

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.

Comment thread src/wrap-require.ts
}

try {
return target.apply(thisArg, [moduleID])

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Choose a reason Spam Abuse Off Topic Outdated Duplicate Resolved Low Quality

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. 😬

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Choose a reason Spam Abuse Off Topic Outdated Duplicate Resolved Low Quality

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 Apr 21, 2021
edited
Loading

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Choose a reason Spam Abuse Off Topic Outdated Duplicate Resolved Low Quality

Fixing in #136

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Choose a reason Spam Abuse Off Topic Outdated Duplicate Resolved Low Quality

Thanks!

This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants


Back | FazBrowse Home | New Git URL