Remove namespace folder and use string replacement

[scolladon]

Who is the bug affecting?

Developers and Maintainers

What is affected by this bug?

duplicated code

When does this occur?

building the code with namespace

Where on the platform does it happen?

during the tests and the deployment

How do we replicate the issue?

Just run a PR

Expected behavior (i.e. solution)

Code should not be duplicated

Other Comments

Use sf cli string replacement solution

[zenibako]

Can you add more detail on which part of the codebase is affected?

I use this code within a namespaced package and have experience with string replacements, so I'm thinking I could contribute.

[scolladon]

Sure @zenibako !

We have the class ApexMockeryOverview which is duplicated in the code base so we can simulate when the code is hosted in a managed package and test this scenario.
This way we ensure non regression in other execution context and we make sure everything works fine wherever it is executed.

The code is duplicated 🙄 and we could forget to maintain both when one evolve (for example).
Using sf cli string replacement could help us having only one class to maintain while being able to test with and without namespace.

Where we are not sure is for the developer experience, we want it to be as easy as possible for developer using the lib to understand how it works and we are wondering how confusing it could be to see code in the repo with string replacement. Even if it is sample code (and not production code).
We are wondering the approach :

• Should we use Mockery. as the pattern for string replacement ?
  • when testing namespace we could leave it
  • It will still be readable in the code base
  • It could lead to confusion for developer using the lib and reading the doc, with question like : "Should I use namespace in production code as well ? 🤔"
• Should we use <clear-pattern-not-confuseable-with-namespace> as the pattern for string replacement ?
  • when testing namespace we could replace it with Mockery.
  • when testing without namespace we could replace it with empty string
  • It will mix our recipes with our test strategy 🙂‍↔️
  • It will be less readable in the doc

Other consideration: refactor this test strategy so it is separated from the recipes (create another class so both our recipes and tests are unrelated).
This way we can do whatever we want with the pattern for string replacement without considering the cognitive load of the developer using the lib when they read the documentation and the code base.

What is your view on that @zenibako and @LudoMeurillon ?

[zenibako]

@scolladon I already gave it a shot and made a PR for it, but my take is we do one of the following:

• use namespace. as a parser-friendly pattern for the replacement.
• use %%%NAMESPACE_DOT%%% to follow the same pattern that CumulusCI uses.

I think including some detail in the README should be sufficient to clarify this behavior. I can revisit later, or maybe one of you will look it over before me.