Cannot find name 'Fluxxor' && 'Import Fluxxor' - multiple conflicting Intellisense detections

[dbaeumer]

From @jwulf on November 24, 2015 12:49

Copied from original issue: microsoft/vscode#544

[dbaeumer]

From @jwulf on November 24, 2015 12:51

This is on a Mac.

[dbaeumer]

From @jwulf on November 24, 2015 13:5

Perhaps it is the * as Fluxxor?

import * as Fluxxor from 'fluxxor'

Nope. It's still there with:

import Fluxxor = require('fluxxor');

[dbaeumer]

@jwulf would you be able to share a folder with me that shows the behavior.

[dbaeumer]

From @unional on April 15, 2016 20:51

Just encountered this also.
The code runs fine on tsc but error on vscode (ts language service). Here is how to reproduce:

// s.ts
export class Foo {}

// m.ts
import { Foo } from './s';
declare namespace Foo { };
export = Foo;

// c.ts
import * as Foo from './m';

console.log(Foo);

[dbaeumer]

From @unional on April 15, 2016 20:51

Reference:
typed-typings/npm-any-promise#1

[dbaeumer]

From @unional on April 15, 2016 20:57

I tested this on Windows.

Code: 1.0 🎉
Also tested with TypeScript@next using settings.json/typescript.tsdk: 1.9.0-dev.20160415

[dbaeumer]

@unional thanks for the code test case. I am moving this to TS since the seems to be caused by the reexport in m.ts

[sandersn]

There is an error in this code, but it's not being reported at the right place. In m.ts, there should be a duplicate identifier error:

// m.ts
import { Foo } from './s';
declare namespace Foo { };
                  ^^^
                  Duplicate identifier 'Foo'.

This is because imported identifiers don't merge with anything else.

[sandersn]

@ahejlsberg pointed out offline that the compiler assumes that symbols are either aliases (imported/exported symbols) or local declarations -- never both. So as soon as export = Foo sees that Foo is locally declared, it exports only that. It never looks for the imported class Foo and never tries to merge them.

That means the code in m.ts is actually legal, but probably not what you wanted. Probably you want to use a module augmentation instead:

// s.ts
export class Foo {}

// m.ts
declare module './s' {
  namespace Foo { };
}
export var dummy = 1;

// c.ts
import { Foo } from './s'; // import from ./s instead of ./m
console.log(Foo);

[mhegazy]

@sandersn there are cases where the error is not reported. but the export behavior is not what is expected. we should raise these as errors .