Can't import namespace that doesn't match dir name

[njaczko]

Copying an issue over from api-specs: https://github.com/LiveRamp/api-specs/issues/324

It appears that trying to import a namespace whose name doesn't match the name of the directory doesn't work. See description of https://github.com/LiveRamp/api-specs/pull/323

[cjea]

I think this is by design, but the docs mistakenly call it a "namespace" instead of "directory". The code doesn't lie though: https://github.com/LiveRamp/reslang/blob/master/src/genbase.ts#L301

Seems that import is meant to work with a directory, not a namespace.

https://github.com/LiveRamp/reslang/blob/6cd79241a5490446ae35dae0b1193019f56eb3a5/src/genbase.ts#L211

[ChristianHansen]

Even when using the directory name, I'm running into issues that seem potentially related to the refactor to move specs into specs-draft and specs-production from the top-level. For example, when trying to generate the OpenAPI spec from this commit https://github.com/LiveRamp/api-specs/pull/317/commits/c94f26048ad187daeba3bc17f1e796cc88c1f1c6 I get Reslang error: ENOENT: no such file or directory, scandir '/app/reslang/dm-field-api' when running ./generate-specs.sh specs-draft/field-mapper.

[ChristianHansen]

@cjea ^^

[cjea]

Yup, this looks like a bug with api-specs repo as opposed to reslang. For better or for worse, reslang is behaving as expected lol

I can try getting a PR up on api-specs tonight. Mind if I close this issue?

[cjea]

https://github.com/LiveRamp/api-specs/pull/331 is up for review. I'll close this issue now, but Chris feel free to re-open or create a new one in api-specs if this doesn't solve the issue

[ChristianHansen]

I think this section of the reference needs to be updated as well to say that resources should be referred to by otherdirectory.Resource as opposed to othernamespace.Resource unless it's unintentional that one has to use otherdirectory.Resource.

For example if I change this line to fieldId: linked dm-field-api.Audience, then the Swagger Spec generation succeeds. Note that dm-field-api is the name of the directory, not the namespace.

If the otherdirectory.Resource approach is intentional the the example namespace in the reference manual shouldn't include a slash, since only peer directories can be imported.

[ChristianHansen]

Also, let me know if this should be a separate issue, but I'm running into an issue where trying to have a linked property that links to a subresource in another directory causes OpenAPI spec generation to fail.

For example, changing this line to fieldId: linked dm-field-api.Audience::Field yields Reslang error: Cannot find definition for Audience when running ./generate-specs.sh specs-draft/field-mapper.

[cjea]

https://github.com/LiveRamp/reslang/pull/135 fixes the broken imported subresources.

And yes, I've discovered that namespaces are never used, and only the directory name. For example, given a peer directory other/ that declares a namespace other/namespace/doesnt/matter, resources must be referenced as other.Resource (and not other/namespace/doesnt/matter.Resource).

[cjea]

https://github.com/LiveRamp/reslang/pull/136 Updates the docs

[cjea]

Closing since this is fixed, but please re-open if anything was overlooked