Unlocked Package namespace strategy

Unlocked Package namespace strategy

• Status: review
• Date: 03-04-2023

Technical Story: #36

Context and Problem Statement

The classes shipped in unlocked package created for the v1.0.0 release are not accessible outside the namespace mockery, because the classes and methods access modifier is public where they should be global.

Test.createStub() can only create stub from the same namespace.

Meaning code outside our namespaced managed package cannot be stubbed using our Mock.forType methods and need to use code inside their namespace to build the stub.

System.StubProvider implementation does not have the same constraints and can be used cross namespace.

Decision Drivers

• maintainability
• developer experience
• admin experience

Considered Options

• Unlocked Package without namespace
• Unlocked Package with namespace

Decision Outcome TODO

Chosen option: "{option 1}", because {justification. e.g., only option, which meets k.o. criterion decision driver | which resolves force {force} | … | comes out best (see below)}.

Positive Consequences

• the package is installable, no matter if the target org is namespaced or not.
• the solution shipped is usable across namespace.

Negative Consequences

• we need to delete previous package version to prevent user from installing it

Pros and Cons of the Options

Unlocked Package without namespace

This solution remove the namespace from the unlocked package created.

It fixes the issue of accessing Test.createStub from the Mock class for unnamespaced type. The solution is not installable inside a namespaced org and requires customer to deploy from source or to build their own package with their namespace from the sources.

In order to work with namespaced code, the stub need to be built from inside the namespace and then passed to the Mock using the MockFactory sample provided.

MockFactory need to be packaged inside namespace to be used with namespaced code. It cannot be part our the package

• Good, because it allows to write shorter code (no need to add namespace)
• Good, because it does not need global access modifier change in the code
• Bad, because package is not installable inside namespaced org
• Bad, because type from other namespaced need to be stubbed inside their origin namespace using MockFactory

PR with this solution #37

Unlocked Package with namespace

It needs to transform public access modifier to global for needed methods.

The solution is installable inside a namespaced org.

In order to work cross namespaced, the stub need to be built from inside the namespace and then passed to the Mock using the MockFactory sample provided.

MockFactory need to be either deployed to be used with unnamespaced code or packaged inside namespace to be used with namespaced code.

It cannot be part of the package

• Good, because the code is under a namespace
• Good, because the solution is installable anywhere
• Bad, because type from other namespaced need to be stubbed inside their origin namespace using MockFactory

PR with this solution #38

Links

• Package namespace collision
• Test.createStub() namespace mechanism