Hmmm...this is interesting. So just to be clear, this happens when you retrieve a type from that unlocked package and not based on how that unlocked package is rendered into the OST, correct? Right now retrieved metadata only assumes the namespace of the org associated with the project's(/module's) connection. There's currently no distinction for metadata from installed unlocked packages with namespaces.
As a workaround, what if instead of retrieving that metadata you remove it locally and regenerate your OST? Is the metadata for that installed unlocked package rendered into the OST with the correct namespace. Can you tell I haven't done this yet?!
For convenience, is this a package I could install? That would allow me to try this out a bit without having to create a namespaced unlocked package first.
Okay, I've just committed a partial fix for this, in this case to prohibit subscription to/retrieval of/etc. most of the contents of installed unlocked packages with namespaces. I basically allow the user to work with the same metadata types that are considered subscriber-editable in installed managed packages and no more.
I did investigate just making IC2 support local copies of retrieved Apex (and other metadata) files from namespaced unlocked packages, but the issue is that while the retrieved copy does add a namespace qualification to the retrieved filename, e.g.,
namespace_TypeName.cls
, no internal references are qualified. So if the implementation ofTypeName
referencesOtherTypeName
from the same namespace, it appears in the retrieved source asOtherTypeName
instead ofTypeName
. This can create resolution conflicts with local source that might contain its ownTypeName
, much less if you had multiple such packages installed and retrieved. Hopefully that makes sense... Ideally retrieved metadata for these types of packages would be segregated into namespace-scoped areas of the project so that resolution occurs locally first, therefore removing the need for explicit qualifications on internal references.So the next build will at least keep you from getting into the situation that was causing you grief. We'll see if there's much of a demand for installing unlocked packages with namespaces, retrieving the metadata from those packages, and working with it locally. If so...well...I'll deal with that when it's a real issue for folks.