Merging constants with namespaces

[thorn0]

I wrote this in closed #13536 first, but thought it might get lost there, so filing a new issue.

Merging consts with namespaces really makes sense. For a real-world example, let's take a popular library: TinyMCE, writing proper type definitions for which requires this feature. Namespaces are really convenient in this case because all the classes from the API are attached to the tinymce namespace object or to its subnamespaces. In the API, there are normal classes like tinymce.Editor and so called 'static classes' like tinymce.EditorManager which are just a type (interface) plus an object value of this type attached to the namespace:

declare namespace tinymce {
  // normal class
  class Editor {
    show(): void;
    // ...
  }
  // "static class"
  interface EditorManager {
    activeEditor: Editor;
    // ...
  }
  const EditorManager: EditorManager;
  // ...
}

Nothing unusual so far, but there is a plot twist. The namespace object tinymce itself implements the tinymce.EditorManager interface. It could be easily and beautifully solved by merging a const with the namespace:

declare const tinymce: tinymce.EditorManager;
declare namespace tinymce {
  // ... see the previous snippet
}

But unfortunately this isn't allowed. The error message is: Cannot redeclare block-scoped variable 'tinymce'.

[thorn0]

Just noticed it's been discussed in #18394:

#18163 Merge value namespaces with other values

• We can't emit the var statement in this case

Two options:

1. Consider this feature for type definitions (declare ... / *.d.ts) only, not for emitting. That's where it's most useful anyway.
2. In the non-ambient context, require that the namespace declaration should be located after the constant just like it's implemented now for merging function declarations with namespaces.

• Does this merge with the variable or the type?
  • The variable: Now the declared type isn't the actual type?

Just like when a function declaration is merged with a namespace.

• The type: Now you're changing random other types, maybe accidently?

Is it a big deal? When interfaces are being merged, the same thing happens: you're changing random other types.

• 👎 Demonstrate how to type this library using existing mechanisms

It's possible, of course, but it's uglier and not DRY.

[mhegazy]

Is it a big deal? When interfaces are being merged, the same thing happens: you're changing random other types.

that is not true. you are changing the same type. nothing random about it.

[thorn0]

I don't understand what is meant by random. Neither namespaces nor constant declarations create types other than typeof <id>.

declare const tinymce: tinymce.EditorManager;
declare namespace tinymce {
  // ...
}

So what is the problem? The discrepancy between the type annotation and the actual type? I feel like you mean something else.

[thorn0]

Okay, I think I got it. "Does this merge with the variable or the type?" was a question with two alternatives. The answer is "the variable", not "the type". In my snippet above, the type tinymce.EditorManager shouldn't be affected by these declarations.

[mhegazy]

Okay, I think I got it. "Does this merge with the variable or the type?" was a question with two alternatives. The answer is "the variable", not "the type". In my snippet above, the type tinymce.EditorManager shouldn't be affected by these declarations.

but that means that tinymce as a value does not have the type tinymce.EditorManager any longer.. in other words typeof tinymce !== tinymce.EditorManager, which is surprising to say the least.

[thorn0]

Can we add some syntax to indicate that the type annotation isn't final?
Something like:

declare const tinymce: tinymce.EditorManager & ...;

or

declare const tinymce: tinymce.EditorManager & typeof tinymce;

[thorn0]

Seems like there is already at least one precedent where the type annotation doesn't exactly match the actual type: #18043

[mhegazy]

narrowing does not change the type.. it narrows the set of possible values for the type based on control flow. i do not think this is related to the issue at hand.

[thorn0]

It's a bit similar for in both cases we can say that the type from the annotation is substituted with a type assignable to it. Also type guards do the same thing.

[neurolag]

So I just stumbled across this issue while refactoring type-declarations for a module called inquirer.

So for inquirer the export is an object of type PromptModule but at the same time also provides classes like, for example inquirer.ui.Prompt.

Personally I'd write such a module like this:

declare namespace inquirer {
    namespace ui {
        class Prompt { }
    }
}
declare var inquirer: inquirer.Inquirer;
export = inquirer;

But TypeScript is still throwing errors.
Do I understand right that there's still no good way to go?

Personally I don't really like the way the declarations of the inquirer-module are written currently.
https://github.com/DefinitelyTyped/DefinitelyTyped/tree/master/types/inquirer

Cause of TypeScript's lack of merging-support classes are written as interfaces with new-members and all classes and interfaces are hosted in one single file.