Issue 1:
I am trying to work on 5 Minute quick start tutorial for Angular 2. (https://angular.io/docs/ts/latest/quickstart.html). While executing npm install I am getting following errors with typings. I was getting similar errors for es6-shim, but got that resolved after setting http and https_proxy variables.

Any pointer to resolve this issue?

typings ERR! message Unable to read typings for "jasmine". You should check the entry paths in "jasmine.d.ts" are up to date

typings ERR! caused by Unable to connect to "https://raw.githubusercontent.com/DefinitelyTyped/DefinitelyTyped/7de6c3dd94feaeb21f20054b9f30d5dabc5efabd/jasmine/jasmine.d.ts"

typings ERR! caused by self signed certificate in certificate chain

typings ERR! cwd C:\Learning\Angular\a2\angular2-quickstart

typings ERR! system Windows_NT 6.1.7601

typings ERR! command "C:\Program Files\nodejs\node.exe" "C:\Learning\Angular\a2\angular2-quickstart\node_modules\typings\dist\bin.js" "install"

typings ERR! node -v v4.4.0

typings ERR! typings -v 0.7.12

typings ERR! If you need help, you may report this error at:

typings ERR! https://github.com/typings/typings/issues

npm ERR! Windows_NT 6.1.7601

npm ERR! argv "C:\Program Files\nodejs\node.exe" "C:\Program Files\nodejs\node_modules\npm\bin\npm-cli.js" "install"

npm ERR! node v4.4.0

npm ERR! npm v2.14.20

npm ERR! code ELIFECYCLE

npm ERR! angular2-quickstart@1.0.0 postinstall: typings install

npm ERR! Exit status 1

npm ERR!

npm ERR! Failed at the angular2-quickstart@1.0.0 postinstall script 'typings install'.

npm ERR! This is most likely a problem with the angular2-quickstart package,

npm ERR! not with npm itself.

npm ERR! Tell the author that this fails on your system:

npm ERR! typings install

npm ERR! You can get information on how to open an issue for this project with:

npm ERR! npm bugs angular2-quickstart

npm ERR! Or if that isn't available, you can get their info via:

npm ERR!

npm ERR! npm owner ls angular2-quickstart

npm ERR! There is likely additional logging output above.

TypeScript Version:

1.7.5 / 1.8.0-beta / nightly (1.9.0-dev.20160217)

Code

// A self-contained demonstration of the problem follows...

Expected behavior:

Actual behavior:

Issue 2:
This is a refinement of #306, which I believe shows a missed opportunity for eliding import declarations from generated code, as well as a problematic consequence of the current behaviour.

Suppose we have the file code.ts containing:

declare module A {
export enum Color { Red=1, Green=2, Blue=3 }
}

module B {
import Color = A.Color;
}

import Color = A.Color;

then tsc.exe generates the following in code.js:

var B;
(function (B) {
})(B || (B = {}));

var Color = A.Color;

As pointed out by @RyanCavanaugh in #306, the compiler can elide the var Color... statement from inside module B. This is because inside module B, Color is a non-exported local variable and not subject to declaration merging (S10.5 of spec), so its scope is strictly limited to the interior of module B within code.ts. The compiler can thus reliably determine just from the source of code.ts that Color is not referenced anywhere, and elides it.

The compiler does however emit a declaration for the outermost Color, even though it also has no references in the file. This is because code.ts is considered to be part of the global module, because as per S11.1 "Implementation and declaration source files that contain no import or export declarations form the single global module". As such, another file contributing to the global module may refer to Color, so the compiler must emit the var Color at its point of declaration here in code.ts.

So far so good.

Now, we can make code.ts into an external module as per S11.1: "Implementation and declaration source files that contain at least one external import declaration, export assignment, or top-level exported declaration are considered separate external modules". So if we add the line export = A; to the end of code.ts, like so:

declare module A {
export enum Color { Red=1, Green=2, Blue=3 }
}

module B {
import Color = A.Color;
}

import Color = A.Color;
export = A;

then the compiler does elide the outermost Color declaration. The CommonJS output in code.js becomes:

var B;
(function (B) {
})(B || (B = {}));

module.exports = A;

To summarize my understanding of the above results, the compiler can elide an import declaration provided that all three of the following points are true:

The import statement is scoped within an external module;

The variable created by the import is not exported, i.e. it is a non-exported local variable and not subject to declaration merging;

There are no references to the variable created by the import declaration within its entire scope, which is limited to the interior of the external module within the single source file where the declaration appears).

Coming finally to the point, if we add the line var red = Color.Red; to code.ts like so:

declare module A {
export enum Color { Red=1, Green=2, Blue=3 }
}

module B {
import Color = A.Color;
}

import Color = A.Color;
var red = Color.Red;
export = A;

Then the compiler emits (CommonJS):

var B;
(function (B) {
})(B || (B = {}));

var Color = A.Color;
var red = 1 /* Red */;
module.exports = A;

Note that the outermost Color satisfies all three points above, in particular there are no references to it within its entire scope (thanks to the compiler emitting 1 /* Red */ instead of Color.Red. Yet, the compiler still emits the var Color declaration.

Yes it's technically spec compliant, but it also creates seemingly needless problems in the following straightforward situation (as aluded to in #306):

An enum is used as an ambient type within an external module (i.e. the generated JS code contains no references to the enum's symbols, but only JS constants).

It is desirable to reference the enum through a short local alias, rather than having to fully-qualify it with its complete namespace at every reference site.

For example, the workaround for #306 means writing something like:

// Ensure Deeply.Nested.Module.Color is referenceable:
///<reference path="./types.d.ts" />

// CANNOT DO THIS because tsc will emit an unused local
// whose assignment fails at runtime
//import Color = Deeply.Nested.Module.Color;

export = ... // This is an external module

...
switch (color) {
case Deeply.Nested.Module.Color.Red: ... // ...oh
case Deeply.Nested.Module.Color.Green: ... // ...my
case Deeply.Nested.Module.Color.Blue: ... // ...wrist
}

This scenario (wanting to locally alias an enum) is hardly esoteric, but seems not to be possible unless the compiler elides the provably-never-referenced alias declaration.