Produce DX Package
afawcett opened this issue · comments
Create a package per this to ease usage of this library.
I think we have a few options to do this.
Three of the possible options might be as below.
Option A: (One master branch for both #1 and #12)
Assuming we have #12 done already and all classes have the "di_" prefix at master branch.
Then when we package DX (Unlocked) Package (package using the master branch), if we use "di" as namespace, then Injector.cls will be di__di_Injector.cls.
Pros: Only one master branch to maintain compared to Option B.
Cons: "di__di_" prefix looks not so perfect.
Option B: (One master branch for "di_" prefix #12, another branch (maybe call "unlocked_package" branch) for no-prefix for unlock package #1)
Assuming we have #12 done already and all classes have the "di_" prefix at a TO-BE-MARGE branch.
Then we might want to "git branch unlocked_package" when we are on master branch to preserve a no-prefix branch.
Then on master branch we might "git merge TO-BE-MARGE".
Pros: When we publish and upgrade unlocked package versions, we will have a nice looking di__Injector.cls from the unlocked_package branch.
Cons: All enhancements needs to have two sets, one (pull request) for the master branch ("di_" prefix) another (pull request) for the unlocked_package branch.
Option C: (One master branch for "di_" prefix for both #1 and #12)
Assuming we have #12 done already and all classes have the "di_" prefix at master branch.
When we publish Unlocked Package(package using the master branch), if we use "di" as namespace. Every time, we need to preform refactoring to remove "di_" prefix, then Injector.cls will be di__Injector.cls.
Pros: When we publish and upgrade unlocked package version, we will have a nice looking di__Injector.cls from the master branch (after refactoring to remove "di_" prefix). Only one master branch to maintain compared to Option B.
Cons: Every time, we need to preform refactoring to remove "di_" prefix for publishing and upgrading unlocked package versions.
Personally, I prefer Option A to maintain only one master branch with #12 completed ("di_Injector.cls") and probably "DInj__di_Injector.cls" in the unlocked package.
I also noticed that based on this as above, we need to consider global access modifier when we prepare to publish unlocked package. So will Option A branching strategy still workable?
Thanks @PeterLinBiz for the detailed options.
Personally, I'm a fan of an option outlined in #12 to use di_ prefix in names of metadata (e.g. components, pages, classes, etc.) in the force-di folder, then creating an unlocked package for delivering the code.
I'm hesitant to choose an approach that involves namespaces because of the added burden of maintaining "namespace aware" code, especially if that leads to multiple code lines to maintain. And if we deliver this code as an unlocked package, not a managed package, then I don't see the benefit of namespaces over prefixes since it's only a way to help avoid naming collisions in the subscriber's org. This is an open source project so I don't think there's any reason to consider publishing a managed package, which would require a namespace, to hide "intellectual property".
Also, again since this is an open source project, other developers may want to fork this repo and add their own customizations, possibly submitting pull requests. I would not want the burden of namespaces on them either, especially if they wouldn't be able to use the same namespace our code was using.
@afawcett @ImJohnMDaniel thoughts on the namespace vs. no-namespace debate?
Thanks @douglascayers !
The reason that I mentioned option A, B and C above and even global access modifier is that I totally forgot that unlocked package can be (should be for this case) published as no-namespace.
So my Option D (now it is my only one option) is as below.
Option D: (We only need one master branch for "di_" prefix #12 and this #1)
Unlocked package will be published as no-namespace.
Simple and no extra work.
I am with @douglascayers on this one. I would prefer to see the option in #12 where we add a dl_ prefix to all metadata.
That will allow people the ease of easily incorporating the code base into either their own enterprise-org unlocked packages or ISV's managed packages.
I believe the maintenance around supporting a managed package for this project is not trivial over time and will cause more issues than it is worth.
Basically, I am in favor of closing this ticket with no action and let #12 proceed.
We now provide unlocked package for easy install as well as instructions how to install manually from GitHub if desired.
https://github.com/afawcett/force-di#other-resources-on-dependency-injection-design-pattern