come up with strategy for updating Electron and Node

[mykmelez]

The positron/electron/ and positron/node/ directories contain code imported from the https://github.com/electron/electron and https://github.com/nodejs/node/ repositories, respectively. But since the code is imported without a revision/branch identifier, it isn't clear what version was imported, which makes it hard to update.

That's ok right now, when we're just working on getting Positron working like a given version of Electron and Node. But it'll become a problem as soon as we update those files for the first time. So we should come up with a strategy for updating these files that clearly identifies the version of Electron we are currently emulating and the version of Node we're using.

FWIW, the Electron files currently in the repository come from an Electron clone at https://github.com/electron/electron/tree/6041c7edf9fc8ff4d73b0c311200c3953127da3e, while the Node files come from a Node clone at https://github.com/nodejs/node/tree/4bc1cccb228fdfd1a527de0ee1d9cedc6dac87e2.

[Ryuno-Ki]

What about using git submodules?

[mykmelez]

@Ryuno-Ki That's a possibility, and it's one I've been considering. I deliberately didn't suggest it (nor other solutions) in the description because I wanted to separate the description of the issue from potential solutions for it, like Git submodules (which is what Electron uses) and importing dependencies with an explicit version identifier in the import commit (as Node appears to do).

[Ryuno-Ki]

I'm not fit in C++, how do you "import dependencies" in C++? I remember something about linking in my C course at university …

What lines would I have to look out for?

[mykmelez]

I'm not fit in C++, how do you "import dependencies" in C++? I remember something about linking in my C course at university …

The "dependencies" in this case are the Electron and Node codebases, and specifically certain files in those codebases, all of which are currently JavaScript files (but which may in the future include C++ files).

To date, we've imported these files into the positron/electron/ and positron/node/ subdirectories, where by "import" I mean that I copied the files from local clones of those repositories into a local clone of the Positron repository, then committed them. I'm doing more of that work in #26.

But it'd be better to establish dependencies on the Electron/Node codebases as a whole, rather than copying individual files (since the files that Positron depends upon will change over time, and the set of files it depends upon should all come from the same revision); and identify the exact revision for each dependency.

Note that in some cases we'll also modify files in the depending codebases (as I've done in #26), so it isn't as simple as configuring a Git submodule for each one that points to the upstream repository. We could, however, fork those repositories and then configure a Git submodule that points to the fork.

[Ryuno-Ki]

Okay, let me rephrase:

When I create a project using Node I track my dependencies in a package.json and run npm install to install them locally. How does Node itself imports Node's dependencies?

[Ryuno-Ki]

Sorry, but fits my example perfectly:

(Credits: A moment of nostalgia by CommitStrip)

[mykmelez]

When I create a project using Node I track my dependencies in a package.json and run npm install to install them locally. How does Node itself imports Node's dependencies?

I'm unsure. I know they don't use Git submodules, because the repository contains no .gitmodules file. And their dependencies are committed to the Node repository (in the deps/ subdirectory), so they don't use a tool like Git submodules or NPM that maintains a list of dependencies that live outside the Node repository.

They might use something like Git subtree, although I don't see the branches I would expect in that case. Or perhaps they use homegrown tools or manually import code like we're currently doing for Positron.

[mykmelez]

Sorry, but fits my example perfectly:

So true!