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
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.
The text was updated successfully, but these errors were encountered:
Given the following Typescript files, all in the same directory (though directory structure doesn't matter):
When I run:
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.
The text was updated successfully, but these errors were encountered: