Doing custom packages to prepare for 2019.x

We're trying to come up with the best way to manage internal packages in a way that will transition well to the new package manager when it supports custom packages. Something to hold us over until 2019.x and keep 2019.x in mind.

What were thinking of going with is custom package releases should be zip files containing package.json at their root. They could be unzipped into a projects Packages folder. Assuming their package.json is setup correctly, they'll be loaded into the project by Unity. Shared sub-dependencies would be manually managed. In the 2019.x future, that unzipped folder could be deleted and replaced with an entry in manifest.json.

Does this seem like a decent way to handle it?

Other options we considered were:
- Version controlled packages - Such as git submodule or git subtree. The version control our team uses doesn't support this.
- Local NPM packages - Doesn't handle shared sub-dependencies (diamond dependencies) well and is complex for each dev to setup and maintain.
- Host an NPM registry - Seems like a large amount of work to setup. This method was mentioned in a previous thread, https://forum.unity.com/threads/other-registries-than-unitys-own-already-work-nice.533691/

 

Thanks okcompute for the insight in how custom packages will probably be supported!

This does give us more incentive to look deeper into hosting an npm registry.

Though we'll likely stick with the simpleton manually managed xcopy of packages into the packages folder. Seems like it'd transition well if we set up an npm registry. Plus that folder does also serve as a nice separation between code that should be modified and code that shouldn't, which we had some trouble maintaining with *.unitypackages and our required (non-submodule) tooling.