Split the node source from any customizations/patches

[ghost]

Right now it looks somewhat difficult to upgrade node versions for anybody but the maintainers.

[staltz]

How, in practice, do you suggest splitting it?

[ghost]

One way would b such that the patches are separate from the node source and the node source is in a subdirectory or git submodule or or downloaded via script. Another way would be rebased branches with explictly named patches (commits) on top. This last one requires a bit more care, and maybe should be prefixed like [NODEJS MOBILE].

[ghost]

ON this topic, are there instructions on how do the sync currently? It'd be really nice to have fetch built in (from node 18+).

[staltz]

One way would b such that the patches are separate from the node source and the node source is in a subdirectory or git submodule or or downloaded via script.

Working with patch files would be quite painful.

Another way would be rebased branches with explictly named patches (commits) on top. This last one requires a bit more care, and maybe should be prefixed like [NODEJS MOBILE].

I think our current approach in the repo is quite maintainable. We have one massive commit that squashes all of Node.js upstream updates into a single commit, (resolving conflicts) and then we apply our patches as subsequent commits. It's easy to browse our git history.

It's not perfect, but I absolutely prefer this over maintaining patch files. Managing git conflicts with patch files is a nightmare.

[ghost]

How can anybody else update to a different version though? How can we track the issues over time to do it ourselves? I would really like to start using nodejs 18 right now for example.

[staltz]

The source code is really huge, and tracking the (several) issues over time is daunting.

Look at Node.js upstream itself, they take a similar approach to what we do, but for them it's V8 and other deps like OpenSSL. They bring in the whole source code for V8 and apply custom modifications, see example. They don't use git submodules and neither patch files. The exception is zlib which has a patches folder, but in my understanding these patches are authored by the Chromium team, not the Node.js team.

[ghost]

Let me take a different tack with my question here. What are the blockers for using node upstream directly for the android portion of nodejs mobile?

[staltz]

There are many blockers. I couldn't enumerate them here, but they range from .gyp configuration tweaks, configure file tweaks, and source code tweaks.

[ghost]

so what's stopping them from being upstreamed? What do we do when you don't have time to maintain the project? How could i rebase this were i to need node 20? I'm somewhat proficient at fixing various build issues in projects, although my current PC can't really build node in less than 6 hours, so it's rather difficult, but i could do it were I forced to.

[staltz]

so what's stopping them from being upstreamed?

Nothing, but the PR process takes time and the upstream maintainers have their own opinions.

What do we do when you don't have time to maintain the project?

Same as what the community did when Jaime Bernardo didn't have time to maintain it anymore: I stood up.

How could i rebase this were i to need node 20?

Described here: https://github.com/nodejs-mobile/nodejs-mobile/blob/main/doc_mobile/CONTRIBUTING.md

[ghost]

ah, because I'm used to certain contents in CONTRIBUTING.md I didn't look there. thanks.