How to keep assets identical across multiple projects using local UPM packages

[Varneon]

If you have a lot of personal assets like text files, audio clips, models, textures, etc. that you are often using in many of your Unity projects and want to keep identical across all of the said projects, you should look into turning those assets into local Unity Package Manager packages.

Local UPM packages always stay identical, whenever you change any asset inside one project, the same changes will be applied to all of the other projects as well since all of the files are saved in the same shared location. This also means that using the same package across multiple projects doesn’t create duplicate files and saves space on your hard drive.

NOTE: One known limitation is that you can’t save UdonSharp scripts inside packages!

TLDR:
Using local UPM packages allows you to:

• Keep assets in your package identical across projects
• Store files in your package outside of Unity projects
• Save space on your hard drive (only one copy of the files will exist)

---

How to set up new local package:

1. Create new folder where you want the files to be stored (In my case I have a separate folder under Documents dedicated for personal assets)
   

   
   
   

2. Create new text file called “package.json” inside the folder
   

3. Add following information inside the “package.json” file:
   (Replace the name and description fields with your own details)
   Unity documentation for package manifest: Unity - Manual: Package manifest
   

   

4. Open your Unity project and navigate to Window > Package Manager
   

5. Click the “+” icon on the top left corner to open the dropdown and click “Add package from disk…”
   

6. Select the “package.json” file we created earlier to add the package into the project
   

   

7. Verify that your package was properly added, it should look something like this:
   

   

8. Add assets to your package!
   (Since these packages will be only used by yourself locally, following the standard package layout is optional, but you can learn more about it here: Unity - Manual: Package layout)
   You can access files in your package inside your Unity project from Project window under Packages:
   
   Or you can edit files directly in the folder that we created in Step 1

---

And that’s it! Now you should have a local UPM package that you can add to any one of your projects and the assets inside the package will remain identical between projects.

If you want to edit your package’s information, you can click on the package.json inside your Unity project and it will open this view in your Inspector window:

Editing the fields and clicking “Apply” will save the changes and the package information will updated on all projects

---

Unity Documentation instructions for creating local packages:

Unity - Manual: Creating custom packages

---

I hope you found this tutorial helpful. If you found any mistakes in this tutorial, some details remain unclear or you would like to add something, please don’t hesitate to comment below!

Did you find this tutorial helpful?

• Yes
• No

[Luna_Delrey]

Question, what’s exactly the advantage of using packages opposed to Symlinks?

From my knowledge a Symlink would achieve the same but also allow for U# and Udon stuff to be shared between projects.

(For those reading wondering what a Symlink is, a Symlink, also known as a symbolic link allows you to have a folder point to another folder, e.g you can use it to move appdata to another folder, but windows will still pretend it’s at it’s original location)

[Varneon]

I would say that the risk of corrupting your Unity project with incorrect usage of links easily overpowers the inconveniences that small limitations with local UPM packages may cause in this case. (Unity even warns about this as soon as symlink is detected)

This tutorial is mainly aimed at beginners and understanding the basics of UPM will be extremely helpful in the long run, while more experienced users will most likely already have the understanding of their goals and methods for achieving them, such as referencing remote assets through symlinks.