Developer Workflow problems

We have been working towards having a shared repository of packages for some time now. We’ve recently spun up a verdacio server and are using the suggested work around for authentication.

We are now hitting a wall when trying to develop best practices for new packages and for developing additional features or bug fixes into established packages. Previously we had used perforce to import these packages into a folder as a sibling of the /Assets folder. These were sometimes import+ features which allowed developers to write back to the underlying perforce depot directly.


We could import these packages using file pathing. This workflow is clunky in perforce and has a lot of downsides, but a developer could checkout these files in perforce, make edits and commit to the repository.


Example

Manifest.json entry:
"com.levelex.builds": "file:../CorePackages/LevelExBuilds",







After moving to the private repository we are able to share packages more easily, but editing and modifying them has become cumbersome. To make edits we have temporarily modifying the manifest to revert to a local file package which we pull down from perforce.


New Manifest Entry:
"com.levelex.builds": "6.1.0",

Temp Manifest Entry While developing:

"com.levelex.builds": "file:/P4Root/kbaxtrom_WFH_Platform/platform/LXPackages/LevelExBuilds/6.1",



How are other developer working to make new package version and maintain old version?

 

you need to have an internal distinction between releases and in development versions of your packages. in my previous job and my current one we had the exact same issue. Here's a couple of suggestions:

1. Follow SOLID programming principals when developing your packages. Especially the open/closed principal. Since packages from registries are effectively readonly, your team needs to take advantage of how the code it written to be open for extension but closed for modification. An example of this is abstracting out your logic into base classes or abstract classes with virtual or abstract methods or by making use of interfaces. This way if there's a bug in the package, a team member can just reimpliment the code with much of the base functionality but also the tweaks they need. This is great for situations where devs need a custom change that isn't necessarily good for the package generally but is good for the current project they're working on.
2. You could forget the verdaccio server all together and reference your packages as github registries. That way your versioning is dictated by the commits and merges in the master branch

In my previous job and current one I pushed for the first option. It forces devs to think more carefully about how they architect a package and prioritise the combustibility over the functionality. Takes a bit more time but it's worth it in the end.