dev-cli
dev-cli copied to clipboard
oclif
Solution needed for building native/binary modules for Windows (oclif-dev pack:win)
I understand that the oclif-dev pack:win command does not run on Windows -- it is meant to be executed on Linux or macOS. The problem I am having is that my CLI uses several native/binary node modules (files with the .node extension) that npm install --production normally compiles from C source, matching the host OS. If I run oclif-dev pack:win on macOS, for example, the native modules are built for macOS, then packaged inside the Windows installer with pack:win. The CLI then obviously fails to load the native modules when it runs on Windows.
I have found the following related open and closed issues on this repo, but they are all somewhat specific / prescriptive on the solution or requirements. I thought I would create a more generic "solution needed" issue because I am happy to consider "anything that solves the problem". :-)
- #34 Add custom build options to pack
- #52 pack:win exits with error "tar (child): Cannot connect to E: resolve failed
- #66 Windows: 'grep' is not recognized as an internal or external command
- #73 Allow a way to pack and publish without node_modules?
- #96 Could win32 build fall back to zip if 7zip not available?
- #101 Missing modules in windows installer
@jdxcode, to pick up on an year-old comment of yours :-) on issue #34:
There is no support for building the CLI on windows and right now I don't have any plans to change that (they're all written in bash).
Some questions from the perspective of "could I get it to work on Windows", either as a contribution to this project or a fork:
- Is it "just" the bash-related commands that prevent
pack:winfrom running on Windows? - I was trying to run
oclif-dev pack:winon a MinGW bash shell on Windows, just to see what happens. I fixed a couple of errors and would have to fix several more, but I'm not sure if this is "wasted effort" in case there is a more fundamental reason why this approach wouldn't work.- Are you aware of reasons why this approach wouldn't work?
- If it worked, would you consider pull request contributions? (To avoid the effort duplication of maintaining a fork.)
Thanks!
I don’t work on this project anymore but being able to build an installer for windows would do little good without the ability to also build updates that support native dependencies as well
(disclaimer: documenting my thoughts, no idea who would ultimately do this or sign off on it but it isn't going to be me)
If we had support for building on windows then what you could do is have separate CLIs for each environment. That way building/releasing wouldn't require a multi-machine setup to build on different environments. Using something like shelljs would help add in missing unix utilities for windows but we'd still need to have a way to do things like tar I imagine.
It might be best just to make a new CLI or plugin for dev-cli that does the windows building standalone too.
@pdcastro you might be interested in the discussion at https://spectrum.chat/oclif/general/using-native-modules-with-oclif~08d23844-7ebf-4469-9278-7c87a3e210a5.
In short I've got native modules working now, for prebuilt modules only, with this build script: https://github.com/httptoolkit/httptoolkit-server/blob/2ede1bf/build-release.sh
Thanks @pimterry, I've also got native modules sort of working, with a different approach: I've patched the source of the @oclif/dev-cli, qqjs and execa packages so that the oclif-dev pack:win command runs on a MSYS2 bash shell on an Appveyor "Visual Studio 2017" virtual machine. My current patches are here. At the moment, the patches have some hardcoded values, and they are not generic enough for an upstream pull request. I am still experimenting and changing them. At the moment I am also not using oclif's autoupdate feature, and I am not sure how they will play together when I eventually try that feature.
