chore(ci): added test for builded binary

[robertsLando]

@n1ru4l Didn't tested this. But is this what you mean?

[robertsLando]

@n1ru4l If so, maybe we would need to also fork the pkg repo and make it use our pkg-fetch fork. Or we could clone pkg and apply a patch that does this (faster?)

[n1ru4l]

The questions whether we simply should fork everything (or put it in here as a mono-repo in order to have everything co-located) and publish our own versions to npm. 🤔 That way we have more control over everything. Contributing to the other repositories does not really seem to make any sense.

[robertsLando]

I have just tested this (by manually placing an already compiled node binary inside fetched folder) and it works. The problem is that if we use our pkg-fetch fork to compile for example the 12.18.4, pkg will look for 12.18.1 and will try to build that one as it's using it's obsolete pkg-fetch. This is the reason of my previous comment

[robertsLando]

@n1ru4l What do you think it's the best option? I mean fork/publish our own versions or mono-repo? What are the pro/cons of each one?

[n1ru4l]

having a mono-repo instead of a fork allows us to have pkg-fetch and pkg co-located. We can then publish the packages from our mono-repo to npm!

[n1ru4l]

I can come up with a pr that moves the packages over here.

[robertsLando]

@n1ru4l I'm doing it

[n1ru4l]

I would recommend yarn workspaces for that 👌 Make sure to use my fork https://github.com/n1ru4l/pkg-fetch.git#pkg-binary-fork instead of the original fetch-pkg :D

[robertsLando]

@n1ru4l I let you do that so :rofl: Open a new pr for that and we will merge this after that

[robertsLando]

Or... Merge this one and edit the Dockerfile to use the 'internal' pkg and pkg-fetch