Tests to ensure import collisions don't break type generation

[vados-cosmonic]

While this is not actually likely to be a real usage issue.

When generated types are consumed (in particular from a guest, for example), it is possible that WIT namespaces and packages are identically named (along with all their possible exports, fns, resources, etc) -- it seems like there would be an issue (whether at editor/tooling level or as a barrier to tsc) in working out the types.

Another possible issue here is the .wit.d.ts file that is generated that sits at the root of the generated code. The worry is that this file my have two exports (as in exports * from "./interfaces/something") that would collide.

For reference the "recommended" way to use generated types from Typescript is to modify tsconfig.json and modify the compilerOptions.paths config to something like this:

    "paths": {
      "wasi:http/types@0.2.3": [ "./generated/types/interfaces/wasi-http-types.d.ts" ]
    },

For example see wasmcloud's http-hello-world)

Wiring imports via tsconfig.json would obviously solve the issue, but it's unclear if this is what we recommend everywhere/if there is proper documentation around this. It seems more likely that someone might do the following:

import { .. } from "../../generated";

(and in fact, we've seen a bug filed with this usage)

Until jco automatically updates/edits tsconfig.json and we strongly encourage only using imports of the actual package/namespace (i.e. import { .... } from "ns:pkg/interface@v.v.v"), we probably are exposed to this possibility.

It would be great to have:

1. automated test around this problem,
2. automation for downloading and installing jco + use of jco from a test context
3. a test to ensure a trivial project & toolchain works as we expect

We kind of already have (2) and (3) as we do test examples that are in-repo (via running npm run all for all examples), but it would be nice to be more explicit here, so we have a harness for testing e2e from a user's perspective.

[guybedford]

For guest types bindgen we should be generating module "ns:pkg/interface@1.2.3" { ... } style module declarations (not namespaces), which should avoid the name collisions discussed here.

I don't know if the guest types bindgen is correctly doing this today though across all imports.

For example on Fastly's platform, when users write code against it they import our types file here - https://github.com/fastly/js-compute-runtime/blob/main/types/index.d.ts, which in turn has modules like https://github.com/fastly/js-compute-runtime/blob/main/types/backend.d.ts which define the import types.

Then for the export types, the same deduplication that already applies in implementation exports should apply.