Question Add Core Repo to my project

Hello,
i have my own core library . it manages log,ads,iap etc libraries.Currently i copy it to my every project folder. But when i change something i need to update all other projects manually. How can i manage this centralized ?

 

There are two methods that directly address this. Both methods are great, and worked flawlessly for us for several years now:

- Easiest method: use xlinks (writable, if you want to be able to adapt core assets on-the-fly per project): https://docs.plasticscm.com/xlinks/plastic-scm-version-control-xlinks-guide
With this you can have a directory in your project repo actually refer to a different repo (=your core repo), and it transparently/seamlessly integrates with your project (i.e., Unity doesn't even see this, it's just like any other folder in your project. For each project connecting to the xlink core project you can individually decide which changeset it should refer to. This way, you can support different adapted version of your core project in parallel (i.e. including lokal adjustment for your target project). The idea is to create a new long-term "project branch" in your core repo for each project that wants to use it (but not strictly necessary for read-only xlinks and if your project does not need local adjustments of the core assets), and on this branch you can adapt core assets for your individual projects as necessary.
In your actual project you can then create/update your xlink to any changeset on that branch (i,e, you can even switch between different "version" of your core content for any project).
If you use a writable xlink, you can even transparently modify core assets in your actual project, without affecting the functionality of other projects using the core xlink. This will automatically create changesets and sub-branches in your core repo as necessary, without having to open/edit it manually each time.
To synchronize such writable-xlink-changes from several projects, your core maintainer can then from time to time open the core repo, check the individual project branches and their changes, and then merge/integrate (or more precisely: cherrypick) any new features to its /main branch, from which you can update any other project branches. => This feature helps IMMENSELY to synchronize different versions of your "per project" core assets, as they are all inside a single repo, so you can easily diff and integrate them using Plastic itself.
See the xlink guide for more details.

- Comfortable method with a certain one-time effort: create a custom unity package from your core assets, which can be directly added/managed using Unity's PackageManager: https://docs.unity3d.com/Manual/CustomPackages.html
This requires a certain (manageable) effort to re-structure your core assets so that they match the required package structure (such as splitting the hierarchy into Editor and Runtime, creating .asmdef assembly definitions and manage dependencies, and create a package.json that the PackageManager understands), but from that point on you can maintain that package in your core repository, and every project that wants to use it simply installs any desired package version just like a Unity package.
The only thing you need is a package server/hoster. You can either use a community server for this (such as https://openupm.com/ ), but this makes these packages publicly available, which may not be what they want. The alternative is you install such a server on any machine you have available, for example https://verdaccio.org/ . It doesn't require any noteworthy ressources/performance, so you can even run it on your local machine you're working on.
=> Note as with Unity packages, these packages are read-only, and cannot be modified in the local workspace. You'll need xlinks for that. The "best of both worlds" solution for that is, to first prepare your core repo to adhere to the correct package structure as described above, but then use xlinks into that repository to include these packages as "local packages", instead of server-hosted packages which would then be read-only. If you have projects that don't need to (or shouldn't) modify these core assets, you can then have them use the regular PackageManager plus package server, and the projects that should be able to modify the assets can use the local püackages xlink variant. If ALL your projects are fine with the latter, you don't even need the Verdaccio package server.

 

method one looks perfect for me. thank u so much