Feature Request: Export All TypeScript Definitions as Top-Level Named Exports

[BenJackGill]

Is your feature request related to a problem? Please describe.

The @google-cloud/resource-manager package currently requires users to access its interfaces through deeply nested namespaces (e.g., ResourceManager.protos.google.cloud.resourcemanager.v3.IProject). This can be cumbersome and counterintuitive, particularly in TypeScript environments.

The current subpar solution for accessing the TypeScript interfaces looks like this:

import * as ResourceManager from "@google-cloud/resource-manager";

const project: ResourceManager.protos.google.cloud.resourcemanager.v3.IProject = {
    name: 'my-project-name',
    projectId: 'my-project-id',
};

Describe the solution you'd like

I propose that all interfaces within the @google-cloud/resource-manager package (and also other packages if they have the same problem!) be exported as top-level named exports. This change would allow for more straightforward and cleaner import statements, enhancing the developer experience when working with TypeScript.

Benefits:

• Improves code readability and ease of maintenance.
• Simplifies the import process, making it more intuitive for developers.
• Aligns with TypeScript best practices, encouraging more widespread and effective use of the package.

With this change we could easily import TypeScript interfaces like so:

import { Project } from "@google-cloud/resource-manager";

const project: Project = {
    name: 'my-project-name',
    projectId: 'my-project-id',
};

[sofisl]

@alexander-fenster, what do you think?

[alexander-fenster]

I agree that it's not easy to access the nested types. Exporting leaf level message types is a little bit harder than it seems. Problems that we'll need to solve with this approach:

• what to do with multiple versions (google.cloud.example.v1.IProject vs google.cloud.example.v1beta1.IProject). This might require making fixes to the "default version" code that glues the two versions together (currently in synthtool, but might move to Bazel as far as I understand the plans).
• how to deal with name collisions which are unlikely but possible?

From the implementation point of view, the main design principle of the generator is that it does not know anything about the target language (it does not know that it generates TypeScript), so the right way to implement this feature would be:

• add a method or a property to the Api class (or somewhere else) that would return a language-independent list of fully qualified message names that should be exported from the API;
• in a template (index.ts.njk), iterate over that list and generate TypeScript interface names to be exported.

Let's think if we can actually make it work.

---

In the meantime, @BenJackGill I can suggest you could try using namespace aliases as a workaround:

import {protos} from '@google-cloud/resource-manager';
import v3 = protos.google.cloud.resourcemanager.v3;

const project: v3.IProject = {...};

Does it make it easier to use for you?

[BenJackGill]

It does make the code look cleaner but I think many people (myself included) usually try something like import { Project } to see if the type is exposed at the top level and then assume there is no type definition if not found there.

Using namespace aliases looks a little nicer but it doesn't really solve the problem because I still need to know the definitions live at protos.google.cloud.resourcemanager.v3 which isn't intuitive.

Although I appreciate it might not be easy to fix because of the problems you raised.

[alexander-fenster]

Using namespace aliases looks a little nicer but it doesn't really solve the problem because I still need to know the definitions live at protos.google.cloud.resourcemanager.v3 which isn't intuitive.

Yep, this is understood, we'll see what we can do!