Details
I've often wondered why external dependencies are vendored into an externals/ directory instead of using a dependency management tool such as Composer?
The only reason that I can think of is that vendoring the dependencies simplifies the installation process, but perhaps there is more to it than that? Is there a longer term plan to adopt such a tool?
Answers
We do use tools for some externals, and used more tools in the past. Users get these wrong very often relative to how frequently they are used:
- Users very frequently got submodules wrong (forgetting to upgrade them).
- Users had a fair amount of trouble with npm when we last swapped Aphlict over.
- Users have a fair amount of trouble with PEAR and Spreadsheet Excel Writer.
Copying actual files in is just really good on every dimension:
- It's dead simple and users can't get it wrong.
- It has virtually no cost.
- Doing anything else wouldn't really provide any benefits.
- No single package manager can install all of the externals.
- We've modified many of the externals (often security/error handling changes).
- I'm not comfortable with Composer's security model, specifically (T6012).
- I plan to build a package manager eventually (T5055) but would not plan to distribute Phabricator's externals through it.
- My current plan is to copy externals into externals/ indefinitely.
The only real downside is that I don't want to bring huge externals in like this, since that does have some costs in terms of making the codebase more cumbersome to work with. The two cases we've hit of this so far are Spreadsheet Excel Writer and the Jabber/XMPP extension.