node: Add support for Git sources with lockfile v2 processing#351
node: Add support for Git sources with lockfile v2 processing#351refi64 wants to merge 1 commit intoflatpak:masterfrom
Conversation
I believe it would be a fair tradeoff. Our git handling is extremely messy and includes terrible hacks, i.e. dynamic |
Signed-off-by: Ryan Gonzalez <ryan.gonzalez@collabora.com>
c3a96d3 to
21bb9e9
Compare
I mean, we're also building the entire internal cache representation from scratch, I'm not sure if the git handling really stands out here...
Probably worth noting that this includes self-hosted GitHub Enterprise and GitLab, not just fully alternative git hosts. There are also a handful of Electron apps on smaller, currently unsupported instances like Codeberg, and we already have some apps that pull in their own internal deps over git, so I don't think it's unreasonable to believe that someone would eventually combine those two together. |
IMO it does. Massive jq-driven build-time patches are significantly more complex (and probably prone to break) than plain and simple flatpak-builder sources that don't need any post-processing.
Hmm, does npm detect custom GitLab hosts? If it does, can we do the same? |
Fair, tbh if part of the issue is it being in a somewhat strange syntax, it could really just as easily be a Python script. (To be entirely frank, I'm not sure why I went jq here in the first place...)
From what I can tell, this is explicitly not supported in hosted-git-info, and I can't find anything inside npm that would imply it does anything extra here. |
The jq syntaix is fine, I actually love jq. What IMO is not fine is the sheer size of the generated scripts to run at build time. If we can potentially avoid them altogether in 99% case, it seems like something worth a try?
Ideally, I believe we should use generated tarballs where NPM uses them, a fall back to git where it does. |
|
I need support for this for the latest release of Stretchly. Attempting to use this results in the following error when building the Flatpak: |
|
@refi64 Is my review still pending here? |
8c5a0ec to
ea9bfa2
Compare
Note that I left
because using v2 processing for v2 lockfiles breaks missing resolved fields.
(I'm not convinced we should rely solely on the git-to-tarball conversions npm does: losing support for custom Git services isn't great IMO.)