Hi,
I’m experimenting with a project setup where I write Feature Modules in isolation. It’s an architectural benefit in that it isolates features, promotes testable code, and promotes simpler feature re-use between projects. This is easy to support in the manifest, as I can add a file path to the local module dependency.
Working with the new Netcode and Testing suite, however, for each feature I have four modules (client, mixed, server, tests), and this makes the manfiest rather messy. It would be very nice to be able to set up a hierarchy of modules, so that for each feature I could have a root package that had dependencies to the four packages of that feature. But I noticed that dependencies in packages only support the semantic versioning dependencies, and not file or url paths.
Is there any way I can go about adding this kind of hierarchical dependencies in my local packages? Do I have to use scoped registries? For this type of problem it feels a bit overkill?
Thank you.
Hi @pal_trefall ,
Supporting non-Semver dependencies in packages is on our roadmap but we have no ETA yet.
Scoped registries is probably the best way to replicate the same functionality. You’re saying it sounds overkill, but it’s not that hard to set up a Verdaccio server, for instance. YMMV, depending on the number of people who will be using it, their location (local network or internet), their relationship to your company (access over VPN or requires authentication - something we don’t support in scoped registries yet), etc.
Other options might include Git repositories with submodules (since we also don’t support Git-based packages referencing other packages using Git URLs at the moment).
I don’t think you should mind the project manifest.json file becoming “messy” just because it’s listing dozens of dependencies that you’re actually using (any more than e.g. you should care about meta files becoming messy) - and in that sense, creating meta packages that only serve to group other packages to facilitate a bunch of related packages seems to go against that purpose. In fact, grouping your packages such make it convenient to add everything at once, but that’s also a downside, since you might not want everything. If you do need everything every time, then perhaps you should consider merging them into a single package but define separate assemblies (using .asmdef) to split features.
1 Like
Thank you for the fast reply!
I didn’t actually think of a single package file with multiple asmdefs, I think that approach will do just fine for now!
Is folders for package modules (in visual studio) on the todo list? That would be very useful when looking at not just importing third-party packages, but use it for feature moduels as well.
I’m not sure I quite understand what you mean - do you mean grouping C# projects from the same package together under a Solution folder?
In visual studio all items in a package module lists without folders for me, while in-project asmdef projects lists with folders.
Ah, that’s because packaged code is referenced as Assembly references since any change you make to the package code would be done on a local-only, temporary copy in your project cache. Any change you make cannot be reliably shared to others on your team, to build machines, or even reliably kept around on the same machine (the package manager will promptly revert those changes). Note that editable packages, such as those directly located under Packages or referenced in your manifest.json using file:<path> should normally result in a generated C# project (.csproj) with all their code visible in VS.
1 Like
Mine are referenced with the file path in manifest, but I will try to do it in Packages folder to see if it might give me folders then.
Thank you
Hah, putting the module folders under Packages resolved the issue for me, and I can now work on my modules, in all their glory, with folders. Thank you!
1 Like