Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Removing the qualified name restriction on import targets #1166

Closed
vlomshakov opened this issue Nov 14, 2014 · 7 comments
Closed

Removing the qualified name restriction on import targets #1166

vlomshakov opened this issue Nov 14, 2014 · 7 comments
Labels
Good First Issue Well scoped, documented and has the green light Help Wanted You can do this Suggestion An idea for TypeScript
Milestone

Comments

@vlomshakov
Copy link

It seems to me, it's very inconvenient, that import declaration can't have none qualified symbol as target. By the reason I have to use next way to do this:

class S {}

export type SS = S;
export var SS = S;

Maybe, removing the qualified name restriction will be more convenient than combination of type alias and var alias.

@mhegazy mhegazy added the Suggestion An idea for TypeScript label Nov 15, 2014
@mhegazy mhegazy mentioned this issue Dec 9, 2015
@mhegazy mhegazy added the In Discussion Not yet reached consensus label Dec 9, 2015
@mhegazy
Copy link
Contributor

mhegazy commented Dec 9, 2015

Another use-case described in #3832

@RyanCavanaugh RyanCavanaugh added Help Wanted You can do this and removed In Discussion Not yet reached consensus labels Jan 4, 2016
@RyanCavanaugh RyanCavanaugh added this to the Community milestone Jan 4, 2016
@RyanCavanaugh
Copy link
Member

Approved.

There is some slight subtlety here -- consider the following code:

namespace X {
  interface window { }
  export import Y = window;
}
// What is the meaning of X.Y?

You can think of two different resolution algorithms that we could use on line 3:

  • For each meaning of window (type, value, namespace), resolve that identifier under that meaning.
    • This would mean that Y had the type of the local interface and the value of the global name window
  • Resolve window looking for any meaning. Use all meanings which that symbol points to.
    • This would mean that Y only has the type of the local interface

The second interpretation is more predictable and is more likely to be what's intended.

@mhegazy mhegazy added the Good First Issue Well scoped, documented and has the green light label Jan 5, 2016
@jbcpollak
Copy link

This is labeled as easy, for someone who is a novice to TypeScript could some guidance on implementation be added to the issue so we could look into contributing a PR?

@abhinavramesh8
Copy link

I agree with @jbcpollak. Even I feel that there should be some amount of guidance.

@mhegazy
Copy link
Contributor

mhegazy commented Apr 26, 2017

I would start looking at getSymbolOfPartOfRightHandSideOfImportEquals. this function assumes that the target is a Namespace, and thus looks it as such. this will fail, and you would get an error like "can not find namespace 'foo'". I would unify this function to always resolve SymbolFlags.Value | SymbolFlags.Type | SymbolFlags.Namespace, write some tests, and see what else breaks..

@RyanCavanaugh RyanCavanaugh modified the milestones: Community, Backlog Mar 7, 2019
@exx8
Copy link

exx8 commented Oct 7, 2019

Is this still a problem? as I was able to do this:
A.ts:

 class A {

}
export =A;


B.ts

import A = require("./A");
let a:A=new A();

on 3.6.3

@vijaya-lakshmi-venkatraman

Hi,
Is this still available?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Good First Issue Well scoped, documented and has the green light Help Wanted You can do this Suggestion An idea for TypeScript
Projects
None yet
Development

No branches or pull requests

7 participants