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

Single-file generation based on import #1384

Closed
spencerwi opened this issue Dec 5, 2014 · 1 comment
Closed

Single-file generation based on import #1384

spencerwi opened this issue Dec 5, 2014 · 1 comment
Labels
Duplicate An existing issue was already created

Comments

@spencerwi
Copy link

Given the following Typescript files, all in the same directory (though directory structure doesn't matter):

/* this is A.ts */
class A {
    name: string;
}
export = A;
/* this is B.ts */
import A = require("./A");

class B extends A {
   age: number;
}
export = B;
/* this is C.ts */
import B = require("./B");

var someB: B = new B();
b.name = "John Doe";
b.age = 9001;

When I run:

tsc --target "es5" --module "amd" --out app.js *.ts 

I would expect to get a file containing concatenated output of the modules, preferably resolved by traversing the imports. Instead, I get an empty file -- which is rather confusing for a user expecting to see compiled typescript in his/her output file.

Reading around in the documentation (here and on the Typescript homepage), it seems to be quietly implied in one or two places that the way to make this mechanism work is using references rather than imports.

However, that breaks down when I have things that should be imported from separate files for a development build (where I would want each output file individually for easier debugging), but packaged together for a release bundle.

I understand that if you operate on the mental model of everything being in a single file, references make sense. But this requires a developer to have their mind in two states at once: the in-development state that says "these are separate files" and the in-production state that says "these will be a single file after another process finishes with them."

It seems a happy medium that behaves according to normal expectations could be reached by doing something similar to what r.js does for AMD modules, and something similar to what Browserify does for CommonJS modules. Both solutions produce a single file containing named-module definitions that resolve locally within the file per their respective module format spec.

@danquirk
Copy link
Member

danquirk commented Dec 5, 2014

#17 should cover this

@danquirk danquirk closed this as completed Dec 5, 2014
@danquirk danquirk added the Duplicate An existing issue was already created label Dec 5, 2014
@microsoft microsoft locked and limited conversation to collaborators Jun 18, 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