Question

There are people that are writing Backbone applications using a Backbone.d.ts. There are two use cases I want to discuss.

1. Creating backbone applications with modules using an AMD loader (or CommonJS I suppose as well)
2. Creating backbone applications using plain JS

For those in camp 1, it is necessary that the backbone module be defined as external so that the module is able to be imported and included in the define() wrapper.

For those in camp 2, it is necessary that the backbone module be defined as internal module in order to use the intellisense and not require the use of an import statement / define() wrapper.

Question: Is there some other way to define the module so that it can be used in both cases?

---

I don’t really want to have to create a fork just so that you can have either

// required for those using import (1)
declare module "Backbone" { 

or

// required for those not using import (2) and backbone already exists in the global scope
declare module Backbone {

and still be able to get along with your code/intellisense.

Answer 1

This can’t be done using just one .d.ts file because the compiler needs to know what kind of module system you’re using for backbone in order to know what kind of code to generate. You could be mixing and matching internal and external modules within a single file and there’s no way to guess correctly which you were using for backbone in particular.

You might be able to use interface declarations to make it so that you can declare the majority of stuff in exactly one place and have a “backbone-internal.d.ts” and “backbone-external.d.ts” file that referenced that common declaration file, but the extent to which you could do that would depend on exactly what the surface area of the API looked like.

TL;DR: Camp 1 and Camp 2 are not mutually exclusive, even within the same file.