Use existing star import instead of adding new import

[mjbvz]

From @chrmarti on October 31, 2017 16:58

• VSCode Version: Code - Insiders 1.18.0-insider (81cca6c, 2017-10-31T06:24:27.011Z)
• OS Version: Linux x64 3.13.0-108-generic
• Extensions: none

---

Testing #37177

Steps to Reproduce:

1. Use a global completion when a star import is already in the file:

import * as b from "./bar";

foo|

2. Result:

import * as b from "./bar";
import { foo } from "./bar";

foo|

3. It would make sense to reuse the existing import.

Copied from original issue: microsoft/vscode#37314

[grantila]

What if two modules share exported function names, should import order matter? Or should that automatically be an error? So, if I add an exported function in a file, all of a sudden other code can break and fail to compile? This magic will cause code to be much harder to follow, to know where magic functions come from. It will force people to use IDE:s to be at all productive.

How about (what probably most ES:ers and TS:ers have tried to do and failed):

import * as b, { foo } from "./bar";

I simply cannot understand why the above is not yet legal. It would solve your problem and introduce zero issues.

[mhegazy]

How about (what probably most ES:ers and TS:ers have tried to do and failed):

We are not planning on adding any new syntax to modules that are not in the ECMAScript standard already. Please see design goals, specifically 6 and 8.

[grantila]

@mhegazy makes perfect sense, this surely is an upstream (ES) design flaw.

But then, changing how it is used (polluting the global scope with magic functions) shouldn't be done either, but you added this to the 2.7 milestone. Why? This is not aligned with point 6.

[mhegazy]

But then, changing how it is used (polluting the global scope with magic functions) shouldn't be done either, but you added this to the 2.7 milestone. Why? This is not aligned with point 6.

I am not sure i understand what you mean.. what changing the scopes, and what is polluting the global scope?

[grantila]

Well, I'm not sure what the | is supposed to mean in the examples, perhaps this is just some editor auto-completion thing. The title of this issue, and the examples, seem to suggest that one shouldn't have to explicitly import foo. It should be globally available anyway. That is pollution, and will cause the issues I described, e.g. with collisions etc.

[ghost]

@grantila This issue is for an import fix, meaning the sample code in the original post would not compile and would need to be fixed by changing foo to b.foo. The behavior of the language won't change, but completions will have a different effect in the editor.