Namespace obstructs external contributors from working on code

[ipavlic]

79f5465 added mockery namespace to sfdx-project.json. External contributors do not have access to the dev hub with that namespace registration, which causes sf org create scratch --definition-file config/project-scratch-def.json to fail.

Temporary removal of the namespace from the sfdx-project.json successfully creates the scratch org.

[zenibako]

#78 attempts to address some of the namespace issues, but it doesn't remove the actual namespace from the sfdx-project.json.

Based on the latest docs, using sf org create scratch --definition-file config/project-scratch-def.json --no-namespace should bypass the need to modify the sfdx-project.json file. Can you try that?

[ipavlic]

Sure, that works. I think the real question is who is this library aimed at? Is it regular orgs or to be embedded in other packages?

[scolladon]

Sure, that works. I think the real question is who is this library aimed at? Is it regular orgs or to be embedded in other packages?

Originally we wanted the lib to be usable in both situation

[ipavlic]

@scolladon As is, it's not usable for ISVs without extra work, and the only benefit of a namespace was to avoid name collisions.

[scolladon]

@scolladon As is, it's not usable for ISVs without extra work, and the only benefit of a namespace was to avoid name collisions.

Then maybe we could improve the description here ?
Letting the ISV know they should replace all the global by public so they avoid exposing those class/methods, if they include it in their package (they should avoid that using specified unpackaged metadata) ?

[ipavlic]

This is up to you, and use cases you'd like to support. I found that just distributing raw code was easiest for me.

When using this for other packages, I only use:

• src/classes (Argument, Expect, MethodSpy, Mock)
• test/package/unit (ArgumentTest, DummyInterface, ExpectTest, MethodSpyTest, MockTest)

Everything else is superfluous for me.