Add per package hooks mechanism for handling problematic packages #37
Replies: 2 comments 1 reply
-
There is already a way to patch files, see Line 672 in c279732 for example I use this in my package.json to fix pino, it will find the first string and replace it with the second one "pkg": {
"patches": {
"./node_modules/thread-stream/lib/worker.js": [
"fn = (await realImport(filename))",
"fn = realRequire(filename.replace(/file:\\/\\/?/, ''))"
],
"./node_modules/pino/lib/transport-stream.js": [
"fn = (await realImport(toLoad))",
"fn = realRequire(target)"
]
}} About the other features I'm open to that but we would need to make pkg more usable from code because ATM it only allow to pass a list of arguments, it would be useful to pass the options directly |
Beta Was this translation helpful? Give feedback.
-
Yeah, I saw there is a way to patch code, the problem I was having is with native addon modules, where I need custom implementations of how to grab the right binaries for each platform. |
Beta Was this translation helpful? Give feedback.
-
When you hit a problem package, e.g. a package that is a native addon module, with no prebuild, or that uses napi (Which the current prebuild support hack doesn't work with), you are left in quite a bind as to make it work. The current workaround I use is to have a wrapper script around pkg that will modify the necessary packages on disk before invoking pkg per target. But that's obviously much slower as pkg now needs to do it's entire thing per target rather than for all targets at once, and is also very clunky and annoying to get working.
If instead pkg add a hook mechanism per package, which you can then use to modify the package like the builtin prebuild hack does before grabbing its file per target, it could make it possible to write such hooks to support any such problem package, from downloading custom prebuilt binaries, to supporting other prebuilding scripts or custom URLs, etc.
Another issue is to be able to include/exclude scripts/assets per platform to reduce the size of the resulting binary. Which can be handled by such hook if given the ability to do so, or by adding support for per platform/arch include/excludes of scripts/assets. This is another thing I had to handle with such a wrapper script.
This is kind of an extension of the builtin dictionaries mechanism that isn't documented. Which is a mechanism that could be cool to extend and document for other to contribute definitions for and to make it easier to supply external ones.
Beta Was this translation helpful? Give feedback.
All reactions