Programs implemented as triple scripts are expected to vendor their dependencies. In other words, maintainers should distribute third-party code in the same source tree as the project's own code. If using version control (e.g. Git), the third-party modules (i.e. the content of those modules—not pointers to their entry on some external package repository) are expected to be checked in to version control system. The triplescripts.org group's approach to publishing is not compatible with the package.json convention from the NPM ecosystem (or indeed many of the other traditions in the NodeJS world).
For programs which are not implemented as triple scripts but *do* adhere to the build manifesto (i.e. they use a triple script-based build system), program dependencies MUST be either vendored as well OR provide some means of obtaining ALL third-party code necessary to build the program in a single-shot (preferably with a single HTTP GET request to a user-visible URL).
This strategy differs from the workflows that have arisen regarding contemporary "modern" package managers (which generally operate using pointers and semantic versioning). There are several reasons for this:
- Programmers have demonstrated some combination of a poor grasp of the semantic versioning scheme and/or poor execution in their attempts to adhere to it
- By embedding the contents of dependencies into the same source tree or providing a single-shot means of obtaining all third-party dependencies, it's much easier for maintainers to get things "right" with respect to the separation between source acquisition and the build process, particularly so that the separation remains clear for those downstream
- In traditional systems, externally hosted dependencies might disappear, but in the world of triple scripts, the strategy resembles the philosophy of LOCKSS, which can be viewed as an insurance policy against the disappearance of dependencies, but actually goes further than that, by elevating the "resilient" path into the standard workflow
- The systems devised for managing packages in a pointer-based scheme exhibit a complexity that haven't clearly proven to be worth their costs
NB: Even though the triple script approach does not work in terms of semver pointers, programmers ARE encouraged to continue using semantic versioning—it's just that the triple script approach eschews operating on pointers in lieu of direct use of the module contents.
There is no tooling at this time for actually managing package dependencies. The strategy that triplescripts.org adopts will revolve around third-party code as modules managed in-place.