https://pact.io logo
Join Slack
Powered by
so i heard about koffi this week <https://koffi.d...
# pact-js
y
so i heard about koffi this week https://koffi.dev/platforms#supported-platforms pre built binaries for node sound mighty mighty appealing considering the platform support and the amount of grief requiring a full developer tool chain for node-gyp support. I’ve built some aarch64 binaries for windows here https://github.com/YOU54F/pact-reference/releases/tag/libpact_ffi-v0.4.3 managed to get it building with node-gyp after using an unofficial built of v18.15.0 node, in order to get windows arm node bindings ( they aren’t packaged with the official build yet ) but when calling it through pact-js it complains that pact.node isn’t a valid application so more digging required. not going to lie, it’s awfully fun to do this, as a job
t
aarch64 binaries for windows
🤯
😆 1
m
this looks great, especially if it’s actually going to be maintained (unlike the previous ffi lib). That being said, Tim noticed some serious problems with the previous abstractions in FFI and the problems/segfaults/memory issues that were likely to ensue. Hopefully they are addressed in this lib
See also https://github.com/pact-foundation/pact-js/issues/899#issuecomment-1462945915. I believe doing what we need to remove the build chain during install, is just to build a few additional targets and embed them in the package. It will add a bit of size to the distro, but I think it will be manageable
🙌 1
t
especially if it’s actually going to be maintained
I dunno. It’s behind on current Node releases.
sads 1
For example, it supports none of the “current” releases, and only supports “active”, “maintenance” and “end-of-life”
My feeling is - FFI is not the way to go, unless you want to become a Node maintainer
😂 1
🤔 1
y
FFI is v cool, but when things go wrong, they can go seriously wrong and leave the user proper head scratching, plus the complexities of what might be issues in the core, or in the ffi translation layer or in the main code or the users code. Ffi and node, currently just feels gnarly. Bun and Deno seem to have a nicer approach that doesn’t require building any bindings as properly custom code which from experimentation very few languages need. JNI is similar in java. although the panama project looked very cool at being able to use it without having to write wrapper code
i had a bit of a go with node pre gyp for pre building the node bindings and publishing them to github where they can be picked up with an install hook where it will try and get the bindings from the release location otherwise try and build from source ( as current ) i personally would prefer to have slimmer npm packages and download required libs at run time, the current weight of the pact-core is 215mb ( it includes the standalone aswell ) if we carried pact.node bindings for each node api version and had to store the shared libs, we are hurting a fair few digital trees. i know generally corporates have issues with proxies and install scripts, but i would be the question why are they using npm at all, why aren’t they vetting all code and creating internal mirrors.
re koffi - i looked at the source and some some tests i think but couldn’t see anywhere that was running them. was hoping it would be an omission and that the docs aren’t up to date
m
All good points Saf
i know generally corporates have issues with proxies and install scripts, but i would be the question why are they using npm at all, why aren’t they vetting all code and creating internal mirrors.
It’s hard to build a mirror though, when your code’s 
postinstall
script needs to pull artifacts down dynamically from Github
It was a really big pain point for some of PactFlow’s enterprise banking customers, who understandably, don’t like the idea of an arbitrary script running after 
npm i
happens where any file from the internet can make their way onto a dev machine 😉
😳 1
t
I can see why that would make someone uncomfortable
nod hmm yes 1
2 Views
Open in Slack
PreviousNext
Powered by