Package Developers, How do you handle common assets in different packages?

Hello Package Developers,

I have this problem where I have common, mostly utility, scripts across my packages such as, say, a singleton class. What I’m currently doing is to include a copy of these classes in each of my packages and the issue arises when I happen to improve one such common asset and I want the change to be reflected across all packages.

Manually copying the change across projects seem tedious. The source code of my packages is version controlled using github and I host my packages on NPM. Unity’s package manager cannot seem to automatically add dependencies without a user manually adding the dependencies to the Scoped Registry fields, so that’s out of the question.

I haven’t tried using git submodules to host these common assets that I can reference and pull changes from. I’m not sure how well github supports them, so gotta research that soon.

Anyways, please let me know some of the ways you devs handle this issue.

Sliptrixx.
Hibzz.Games

Apply single responsibility principle.
Will solve the issue.

You can put your common asset as separate asembly, to keep it decoupled. Also avoiding this way any circular references.

Github supports submodules. However, requiring the user to use submodule is not the right idea, and submodules will not save you from having duplicate dependencies.

The reasonable way, I think would be to include a script in both projects that checks if the dependency is present, and if it isn’t, then it would ask user to add it with package manager. I believe TMPro uses something like that automatically.

I think that’s not what he’s talking about.

Let’s say you have a code library. Called “AwesomeLib”.
Then you publish “Dinosaur Controller” and “Destructible Landscape”. Which are published as two separate asset store packages and both rely on AwesomeLib. Ideally you’d want the user to be able to install either of them or both of them without worrying about anything.

1 Like

Oh, I see now.
Providing that what OP meant.