Editing and tracking changes to package files

This may have been asked already, and/or this may run counter to what the PM provides; and in my case, it's very specific to TextMesh Pro.

I'm hoping to add custom rich text tags to TMP. As outlined in this post, that can be done by editing the following file:
TextMesh Pro/Scripts/Runtime/TMP_Text.cs

Previously, if I obtained TMP from the Asset Store, it would become part of my project and could be committed via e.g., git. I could change the file myself, commit it, and then restore my change if some future version of TMP overwrote it.

Now, however, the required file is in the packages folder, outside of my project folder (by design). The file is also marked as read-only (which I can get around). Most importantly to me though, is that any future updates to the package will silently and irretrievably overwrite any changes I've added to TMP.

Again I realise that a lot of this stuff is probably by design, but is there a workaround/best practice for making edits to official Unity packages?

 

Here's a modular approach that I'm using at work. You can make your own local package called com.you.textmeshpro.extensions with its own assembly definition file and namespace and make that package have a dependency on TMP. It could be written to extend/inherit from the APIs provided in the original Unity package. Then you can simply use the types you define there to do whatever you wanted to do.

With this set up, you don't have to care what new version of TMP is released (unless there's some significant API changes) since you're just managing your own versioning for JUST the code that you wrote.

Though this all depends on the exact nature of what custom edits you're doing. Works much better for additions than it does for direct changes.

 

you can embed the package and track it with git.
now it's a manual process:
- copy the package from

Library/PackageCache

to

Packages

via explorer/finder
- strip the version tag (

[USER=473422]@...[/USER]

) from the name, leaving only e.g.

com.unity.textmeshpro

- unmark the readonly status
- return to unity
- now the package is editable and gittable. track your modifications

to update, delete the folder, repeat the process and reapply the diff(s)

 

Hm. I suppose these are a bit similar, just making a copy of the package in my local (tracked) project folder. The change I'm hoping to make is a bit fundamental though (I think), rather than a small extension, so I'd probably go with the second option here.

However, I don't have a folder called Library/PackageCache in my project folder (though there are a few other *Cache folders, it seems). I suppose I can just right-click on the package in the Project view, in Project -> Packages -> TextMesh Pro and choose "Show in Explorer," which brings me to the folder on disk. I can copy that over to my project directory, and "Remove" TMP from my list of packages in the package manager.

I guess the only issue with that is now having to manually check whether TMP's been updated, and proceeding with the manual update as outlined above. Not ideal, but I guess that's the only option for now.

 

Bit confused why you think this would work; now I just get plenty of messages like.

Assembly with name 'Unity.RenderPipeline.Universal.ShaderLibrary' already exists (Assets/Packages/com.unity.render-pipelines.universal/ShaderLibrary/Unity.RenderPipelines.Universal.ShaderLibrary.asmdef)


I'm unable to find any solution to this rather stupid issue.

 

Did you just try it? That reply is almost two years old and a lot has changed in that time. I'll ask the team to take a look at this thread and see if there is anything they can advise.

 

If you overwrite a file in the Packages folder, overwriting the defaults, Unity simply reverts it each time you launch the editor. I found dozens of threads with this issue, but no solution (barring re-copying the file in a script each time you alter anything)

The suggestion in this thread was to make a second copy, not overwriting it, so of course you'll get 'this already exists'

Quite frankly I'm unsure of the point in supplying us with the source code for things like URP if it's not trivial to update it locally.

 

I'll check that - wish I'd found this information somewhere else on the internet!