You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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:
slgorithms.d.ts:
mycode.ts:
mycode.js(es6):
Other Usages:
I'm not attached to the syntax so much as defining the concept here.
The text was updated successfully, but these errors were encountered: