如何强制键入将全局（环境）模块用作外部模块？

Question

I want to use some .d.ts definition in my project, let's say, jQuery. I want to include it like this (or in a similar way)

import {$} from 'jquery';

and not have it in global scope (there are numerous name conflicts in my actual use cases).

But dt~jquery is a global module. Obviously, I get an error:

> typings install dt~jquery --save

typings ERR! message Attempted to compile "jquery" as an external module,
  but it looks like a global module. You'll need to enable the global option to continue.

Can't typings automatically wrap it in declare module (why not)? If not, what is the conventional way of doing it manually so that my repository contributors won't need to worry about it?

I suppose a local modified .d.ts copy is needed. If so, where should it be placed (my typings directory is .gitignored, so custom .d.ts should probably be stored separately and refrenced from typings.json)?

UPDATE: I have just managed to convert jQuery and other global modules to external ones by simply wrapping each in declare module 'module_name' { ... } , placing under a folder I named custom_typings and creating index.d.ts with refrences there. It works fine with my IDE and compiles. The problem is, tsc does not include those imports in my bundled amd output. This is strange, because I had the exactly opposite issue here (tsc included external .d.ts import in js output, which confused webpack).

// modified_jquery_typing.d.ts
declare module 'jquery' {
  ...code from DefinitelyTyped...

  export var jQuery: JQueryStatic;
}

// app.ts
import {thing} from 'actual_ts_file';
import {jQuery} from 'jquery';

// app.js contains .ts import but not .d.ts
define("app", ["require", "exports", "actual_ts_file"], ...)

UPDATE(2) : This was stupid, the jQuery import was simply left out because it was unused. It actually works. Still, I would like to know whether this is the right way to do what I want.

Answer 1

I think you only need import $ from 'jquery'; (no braces) because the export IS what you want, rather than being a module of multiple exports from which you are extracting only one.

Then, are you planning on using both versions of jquery simultaneously? The typings don't need to deal with code that you're not asking the typescript compiler to consider. If you have some no-conflict version of $ being passed in to your typescript code then as usual you'll have to pass around that non-global reference.

That import should also bring in the type definitions you need to strongly type the JQuery typed parameter that you'll be passing around.

===

While I absolutely sympathize with special-circumstance typings and import with typescript confusion, I'm not following your exact desired setup. Type definitions are not private so as far as typescript is concerned, the types will be available everywhere. That's not the same as polluting the run-time global namespace, which a d.ts file WON'T do. The types will be available everywhere to constrain your code, but it doesn't add any overhead to the run-time.

The risk is having an ambient definition for the $ name whereas at runtime, it won't really be there - defeating the purpose of the strongly-typed environment in that particular way.

What happens if you just say import 'jquery' and don't define a $ ? I imagine that you'd still be able to refer to the types to pass around a scoped, no-conflict jquery object, but that perhaps typescript will not define $ with that usage?