To aid with package development in teams, especially when developing a package “live” inside a project, it would be very helpful if we could have a packages-override.json or user.json that overrides where to source a package from (by identifier)
Why? Let’s say you have a package shared between multiple projects, an in-house framework of some sort. It builds up over multiple projects, and you want to use it through UPM
Right now if you want to edit it while working on a project, you have to edit it as a separate repo, push it up to your VCS, then pull it down via UPM using Git or if your VCS supports it the package repo (we use Gitlab). That workflow sucks.
The better workflow is that the version controlled manifest.json points to the package repository. Great! Then you as a dev have a local copy you’ve pulled down outside of the directory structure for the project, and inside your user.json, packages-override.json, whatever (which remember isn’t pushed up to git) you override where to source the package from to be from the local copy on disk instead. You work on the project, edit the package, then when everything is fine and dandy you push the project up, the package up, and the rest of your team are using the package from UPM’s pull from your package repository, not the local copy because the override isn’t committed to VCS
The only thing I can think of that would achieve this right now is to pull down the package inside the project as a working copy inside another working copy and add it to .gitignore, then the pulled down package will override the UPM package. But it’d be much nicer if there was a native workflow for this, especially if the package is being worked on across multiple projects at the same time (e.g. it’s an SDK package)
Related to this, we were thinking of writing some tool to aid switching a package path from registry to local folder for development. Wed like to avoid writing an external tool, but I don’t think there’s a way of running a script and/or displaying a window in Unity after opening a project but before the packages load.
The packages-override.json would also be useful to add certain editor tools that, for example, artists need but developers don’t. The only way to do this now is to have different Unity projects that share a package.
I think the packages should’ve been forced to be split into two categories: The ones that are required to load a project successfully and without it you will get errors on play and build, and those packages who are an editor tool that are not required to load the project (like UI Builder, maybe Shadergraph but haven’t tested it, but it could be a candidate). Now it’s up to the package author to decide this split, which rarely happens.
Incidentally you basically described how NPM works, as you have packages and dev packages, the latter only get installed when you need a development environment (for running tests, etc)