Skip to content

Proposal: Provide Compile Time Instrumentation of "import" #4860

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

Closed
gpickell opened this issue Sep 18, 2015 · 4 comments
Closed

Proposal: Provide Compile Time Instrumentation of "import" #4860

gpickell opened this issue Sep 18, 2015 · 4 comments
Labels
Duplicate An existing issue was already created

Comments

@gpickell
Copy link

After some time with the new ES6 module system, I have found it lacking in the sense that by and large when I use the import, I am not making any intellectual decisions where it comes to importing anything I need. In other words, I write the "import" because I must and for no other reason. The browser does not somehow know all your JS files on the server (nor should it), so the ES6 module system makes sense because it is targeting browser behavior. However, this does not mean that there could not be some better instrumentation of "import" at compile time.

What is currently available are index modules where you re-export everything. However, these are modules themselves and still require you to piecewise import classes. Since TypeScript is aware of all the TS and D.TS files at compile time, it stands to reason that we should be able to address any module component by placing it in a "suite". This then allows code which references the "suite" to automatically have its constituent usages of components from said "suite" without explicitly importing each and every module that is placed in the "suite" nor giving it a local name.

The justification for this is that by and large, developers do not reuse the same file name and if they do, it is in another folder.

slgorithms/quicksorts.ts:

export function quickSort1() {

}

slgorithms.d.ts:

declare suite algorithms {
    import * from "slgorithms/quicksorts";
    import * from "algorithms/hashers";
}

mycode.ts:

import from algorithms;

quickSort1(...);

mycode.js(es6):

import { quickSort1 } from "algorithms/quicksorts";
quickSort1(...);

Other Usages:

declare suite x {
    import { y } from "y"; // Explicitly offer these modules
    import { y as z } from "y";
    import * as y from "y";
    import from w; // Implicitly offer other modules through suites
    import from "y/*";
    import from "y";
}

import from x;
import from "y/*";
import from "y";

I'm not attached to the syntax so much as defining the concept here.

@mhegazy
Copy link
Contributor

mhegazy commented Sep 18, 2015

looks like import * from "module", see #2956

@mhegazy mhegazy added the Duplicate An existing issue was already created label Sep 18, 2015
@mhegazy mhegazy closed this as completed Sep 18, 2015
@gpickell
Copy link
Author

I'm not convinced that the linked issue captures the behavior here.

@mhegazy
Copy link
Contributor

mhegazy commented Sep 18, 2015

my bad. so how is this proposal different from import * from "mod"?

@mhegazy
Copy link
Contributor

mhegazy commented Sep 18, 2015

@vladima pointed the difference to me.

your suite declaration looks a lot like a module with export * from "mod" statements. so why not have that in a module?

Also looks like this needs import * to exist first. and that would be built on top.

@microsoft microsoft locked and limited conversation to collaborators Jun 19, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Duplicate An existing issue was already created
Projects
None yet
Development

No branches or pull requests

2 participants