Repository navigation
Optimize tsc --w using the CoS builder #10879
Description
Activity
This is a tricky problem as changes in one source file can produce errors in other source file such as renaming a function in one file, and not updating the other files to use the new name. So at the bare minimum, you need to re-evaluate error checking in the other source files in the project. In other cases, such as as changing the values of a const enum, you also have to re-emit as well.
I recently wrote my own watch script using the language service API's and wound up writing both 'watch' and 'unsafewatch' tasks. The watch task does the recompilation ala tsc, and the unsafe version does the single file fast turnaround times like you are describing, at the expense of generating code that may or may not be broken.
To do this correctly, I believe the language service API's would need to expose a way to query the interfile dependencies based on which symbols are used and where they are defined. I didn't see anything exposed in the API along those lines when I was working on this, but I think it could be a welcome addition.
I think
--isolatedModuleswould get you part of what you want. The docs for it aren't the clearest, but I think it essentially 'turns off' full-project typechecking and puts tsc into transpilation mode. I use it for fast compilation in webpack projects and rely on my IDE + CI server to catch compile errors.--isolatedModulesis our most confusing flag. What it actually does is validates that your project can be safely single-file-transpiled. This means no usingconst enums, no use of unqualified value names in a merged namespace, etc.. It still performs a full typecheck to do this validation (it has to); a project that does compile correctly under this flag can be safely compiled under a faster transpile-only mode.tsserver already knows how to do this correctly without a flag; we'll be moving the code from tsserver to tsc that can do this correctly for isolated modules
Reacted by normalser, Mike Murkovic, Herrington Darkholme, Aluan Haddad, Pavel Karoukin, Toni Villena, Jonas Kello, Alex, Stanislav Panferov and ZpdDG4gtaReacted by normalser, Aluan Haddad, Toni Villena, Jonas Kello and AlexReacted by normalser, Aluan Haddad, Toni Villena and Josh Ghoulberg 👻Zhengbo Li (@zhengbli) we will need to move the builder logic into program perhaps, and allow it to be used for both compile on save, and --watch.
also related #11229
- changed the title
[-]tsc -w - erase mode[/-][+]Optimize `tsc --w` using the CoS builder[/+]on Oct 3, 2016 1 remaining item
I believe this is a really important issue that influences DX daily, hourly, minutely, and not secondly, but firstly.
Zhengbo Li (@zhengbli) Mohamed Hegazy (@mhegazy) Ryan Cavanaugh (@RyanCavanaugh) - Hi guys, just wondering if there was an ETA on this please? Compile times are killing me...
Reacted by normalser, Agamnentzar, Adrian Blumer, Dasa Paddock, Samuel Magnan and Johannes Schmidcan't look at so many peoples suffering here:
{ "taskName": "quick transpile", "suppressTaskName": true, "showOutput": "always", "command": "node" "args": [ "./node_modules/typescript/bin/tsc --target YOUR_TARGET_HERE --module YOUR_MODULE_HERE --noResolve --rootDir YOUR_ROOT_HERE_IF_NEEDED --outDir YOUR_OUTPUT_FOLDER_HERE_IF_NEEDED ${relativeFile}" ] }- hook the above json into your
tasks.jsonin.vscodefolder, make sure to replace all*_HERE_*placeholders with something meaningful for your setup, add more or remove inapplicable, etc. you should know better - assign this task a shortcut
File->Preferences->Keyboard shortcuts:
add:{ "key": "ctrl+q", "command": "workbench.action.tasks.runTask", "args": "quick transpile", "when": "editorTextFocus" },- go to your TS file with changes and hit
Ctrl + Q - observe the following output
so what just happened? why do i see these errors in the output?
no panic, we just transpiled the current file into JS ignoring all type checks, so we got our JS from TS lightning fast at the price of no gurantees of being correct assuming you know there were no errors
enjoy
Reacted by Marin Marinov, normalser, Tingan Ho, Seravy and Aluan Haddad- hook the above json into your
There is now babel-preset-typescript, that mostly erases just the types.
See: https://babeljs.io/blog/2017/09/12/planning-for-7.0 and https://github.com/babel/babel/tree/master/packages/babel-preset-typescript
Has anyone tried it yet? How fast is it?
The fix should be in
typescript@nexttoday. please take it for a spin and let us know if you are running into issues.Reacted by Kevin, SlurpTheo, Josh Thomas, Mark Florian, Marvin Hagemeister, John Weisz, Jari Pennanen and Grant MathewsLike Aleksey-Bykov we have a similar solution leaning on everyone's experiences to make a gulp watch task
Our typescript full compiles took around 18 seconds, incremental 15 seconds, but whatever visual studio 2015/2017 did it could produce the .js file in the time it took to refresh the browser. So we hooked up a watch to .ts files and compiled the single file.
An example of what we did is here if you're interested (Although it could use cleaning up and changing for your output):// A experiment for quicker builds. gulp.task('watch:typescript:quick', function () { return gulp.watch(files.tsFiles).on("change", function(file) { // Workaround to keep original folder structure var currentDirectory = path.dirname(file.path); var sourceDirectory = 'scripts'; var index = currentDirectory.indexOf(sourceDirectory); var relativeDirectory = currentDirectory.slice(index + sourceDirectory.length + 1); var outputDirectory = __dirname + "\\scripts\\output" if (relativeDirectory) { outputDirectory = outputDirectory + "\\" + relativeDirectory; } var cmd = '"' + __dirname + '\\node_modules\\.bin\\tsc.cmd" --target ES5 --module AMD --sourceMap true --noResolve --outDir "' + outputDirectory + '" "' + file.path + '"'; var startD = new Date(); console.log(startD.toTimeString().split(' ')[0] + ' - File change detected. Starting incremental compilation...'); exec(cmd, function (err, stdout, stderr) { if (stderr) { console.log("Command Failed: " + stderr); } else { var endD = new Date(); console.log(endD.toTimeString().split(' ')[0] + ' - Compilation complete. Watching for file changes.'); } }); }); });Obviously any errors are not reported and it does its best, so a full compile is needed at some point, but for incremental changes we wanted a quick turn around as possible like we can achieve in VS2017.
I will try out the changes to --w and see if it does what we need. Thanks
Mohamed Hegazy (@mhegazy) and team - just to say, we upgraded today (now that the ImmutableJS type definitions have been fixed) and we're seeing some impressive speed improvements in
--wmode.Thank you very much!
Reacted by SlurpTheo, Kevin, Naor Ami and Adam Wamai Egesathanks for getting back to us on this. glad we could make it work better for you.
The change was big, so i would not be surprised if there are issues. please feel free to reach out if you are running into any issues.
Reacted by Seravy and Adam Wamai EgesaWe have switched to using it in production. Our watch builds are down from 14 seconds to 1-2 depending on how dependent the file is. Amazing work, looking forward to that api you say you will expose so other tools can use it too. Great Job.
Reacted by Adam Wamai Egesa- locked and limited conversation to collaborators
on Jun 19, 2018
It would be great if one could run
tsc -w --eraseMode(or something similar) that would allow to simply erase theTypeScriptannotations and hopefully generate js code quicklyRight now making tiny change in one file:
eg.
console.log('test1')toconsole.log('test2')triggers "recompilation" (even if incremental) - that takes some time and keeps getting slower as project grows
VScode already makes a great job with showing errors in a project - and I would be happy to have long (re)compilation with full errors to be part of build process - what I would prefer is ability to have 'instant' change reflection in generated js files
Related to: #10878