Open robertsLando opened 3 years ago
@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?)
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.
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
@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?
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!
I can come up with a pr that moves the packages over here.
@n1ru4l I'm doing it
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
@n1ru4l I let you do that so :rofl: Open a new pr for that and we will merge this after that
Or... Merge this one and edit the Dockerfile to use the 'internal' pkg and pkg-fetch
@n1ru4l Didn't tested this. But is this what you mean?