Tom/deparse PR

[pyramation]

#32 is the original PR, working here to clean up protobuf issues

[pyramation]

NOTE: @tomquist I'm thinking how to address 4.8M that proto.js adds, since this is literally bundling C objects already 30M, maybe it's not much add, but I'm going to consider tree-shaking for the deparser

[pyramation]

another thought, once we get the supabase builds in CI/CD, I think we can get rid of those .a and .lib files

https://github.com/launchql/libpg-query-node/actions/workflows/build-supabase-artifacts.yml

[benasher44]

I was also thinking instead of supabase builds, could we just publish the binaries to npm? esbuild for example does this and publishes the builds for different os/cpu variants as sub-packages, and then you can tweak your local yarn/npm settings to that only the ones relevant to the architectures your app supports are pulled in.

[benasher44]

Looks like they just add them all as optional dependencies: https://github.com/evanw/esbuild/blob/main/npm/esbuild/package.json

[benasher44]

Then these package.json attributes tell package managers whether they're relevant on the current arch: https://github.com/evanw/esbuild/blob/main/npm/%40esbuild/linux-arm/package.json#L14

And then install.js is generated here, which is run by a postinstall script in the main package: https://github.com/evanw/esbuild/blob/main/npm/esbuild/package.json#L10. That script makes various attempts to resolve the path to the binary here (either by the already-installed optional deps or fetching from/via npm)

Anyway the point is that it seems like there's a general path here to publishing as separate packages to npm followed by an install script that resolves the binary path (no need to rely on supabase)

[pyramation]

@benasher44 it's a good idea! I would just need an example of how to fetch from npm cdn without using npm install, is that possible?

[benasher44]

Yep can you see here: https://github.com/evanw/esbuild/blob/886c5456d4edc6094391e9e6fcccb19661621868/lib/npm/node-install.ts#L218

If configured correctly, npm/yarn should automatically get the relevant optional dependencies (based on declared CPU arch, etc.), but if npm/yarn hasn't done that, this method is available to fetch from npm