Closed nahuel closed 7 years ago
Hello, The main problem I think could be with single file emit, which was achievable only in https://github.com/TypeStrong/atom-typescript in Atom in time I was starting this project.
It wasn't even possible with compiler, basically it was some custom implementation patching typescript language server.
plugin-typescript achieve the same feature while loading in browser, and otherwise with tsc/editors other than Atom you'll have to emit all files always, which will always be slower than this approach, and also not scaling, because you'll get even slower with each new module added to your dep chain
Isn't tsc --outFile
single file emit? Besides that, I wasn't talking about using tsc
to compile all the .ts codebase to a single file, but to make tsc
generate a .js file (system/ES5 module format) for each .ts one. Then in development mode tsc --watch
will be run manually or by the IDE, so when you change a .ts file his related .js file will be updated, and systemjs-hot-loader
will be notified to update it at the browser. This is an incremental workflow, only the changed file is compiled and loaded. And in production mode you simply do a jspm build
of all. So generating many system modules will be not detrimental to performance. Besides hot-reloading, I can't see how having many .ts files and making plugin-typescript
load them and transpiling them in the browser can be faster than having the same number of system .js modules precompiled from .ts and making SystemJS load them in the browser without transpiling. Also note in this approach the TS compilation output is persisted on disk, and not transient in browser memory as with plugin-typescript
.
I'm not talking about concatenate outFile, with single file emit what I mean is to emit only modified module without emitting all the other in dependency tree. You cannot do this with tsc, it will always reemit all modules, please try that in some very simple scenario and check modify date of emitted JS files. And because of this issue your hot-reload will stop working correctly as it will always reload all the files.
good point, I think tsc
should re-compile the dependencies only if the signatures exported changed on the updated module. But given the current tsc
behavior, I'm not really sure is slower than plugin-typescript
for practical use cases. Usually tsc sits on background and is very fast, having the compilation results persisted on disk seems to be an advantage, and for many projects you usually don't change core modules with many dependents. Will experiment. Thanks.
no problem, you might also search in TypeScript repo issues something more about this behaviour, maybe something changed in this matter, wish you luck :)
What if:
1- You don't use
plugin-typescript
at all, avoiding any kind of in-browser .ts transpiling. 2- The developmenttsconfig.json
is configured to emitsystem
/ES5 modules to thedist/myapp
folder:3- The
dist/myapp
package is marked in the SystemJS config as having"format" : "system"
, so it doesn't tries to transpile them.Then, you compile TS from your IDE or using
tsc --watch
in another console, and the compilation output will be generated ondist/myapp
insystem
/ES5 format ready for the browser SystemJS consumption.Is this approach better / faster than in-browser transpiling using
plugin-typescript
? What do you think? I was thinking of going in this direction until I found this project, as I don't like to transpile in the browser if my IDE is already incrementally compiling it. This approach seems simpler to me, but maybe I'm not seeing some disadvantage.