This project is read-only.

Ambient declarations and modules

Topics: Language Specification
Nov 7, 2012 at 6:46 PM

There is some discussion around external vs. internal modules that I wanted to post here to make sure that we aren't missing another aspect or using things incorrectly.

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.

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" { 


// 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.

Nov 20, 2012 at 12:40 PM


Nov 20, 2012 at 5:02 PM

You might try your question on StackOverflow.  Given that it's the holidays, and questions like these tend to get more eyes over there, you might have better luck.