Re-evaluate our approach to in-tree dependencies

[mmarchini]

Our current approach to have all dependencies in-tree is optimized for some use cases, like offline development. Since dependencies are tightly coupled to our meta build toolchain, this initiative presents an opportunity to re-evaluate how we handle dependencies. We should understand the benefits and drawbacks of the current approach compared to other approaches (like submodules or depot_tools) so we can decide if we are making the right trade-offs.

[DeeDeeG]

As a person who has built Node a couple of times to contribute PRs, I think the current system with in-tree dependencies is fine. I also had the experience of building V8, and I wasn't thrilled with having to clone and initialize depot_tools to build V8.

FWIW, I weigh in as 👍 for the current approach, and 👎 for anything like depot_tools.

I know I'm just a random contributor (mostly documentation at that), but those are my two cents.

(If anything makes building Node complicated, when looking under the hood of how it works, I would say the Makefile/Windows equivalent (vcbuild.bat) are long and complicated, but I am not sure what a simpler approach would look like.)

P.S. I personally don't think using submodules would be a plus, unless strictly needed. Submodules are okay to reduce the size on disk and number of files of the core repository (effectively: network bandwidth, disk I/O, and storage requirements for contributors and CI), but it just shuffles some of it out to another git repo. And people always forget to initialize the submodule, which can lead to errors like file not found [./something/from/the/submodule]. Syncing a submodule is a little more complexity, but I am not thinking of a good compelling reason to do that. It seems to come in really handy for code you depend on that isn't licensed in such a way that you are able to redistribute it wholesale, but cloning it at build time is acceptable.

(There might be niche cases where, say, a contributor doesn't need to locally modify or build V8, or is comfortable testing solely via CI, in which case not having to sync V8 would save them time, disk space, and network bandwidth. At the cost of inconvenience and complexity for everyone else who does need to actually build V8/whatever dependency is in a submodule.)