Multiple node.js instances

[ttsiodras]

First of all, thanks for doing this - your plugin is an excellent help when working with Typescript.

One problem, though ; Vim is spawning a different node.js instance for each .ts file I am opening. Since I am working on very big TypeScript projects, this ends up eating all my memory very quickly, as I navigate from file to file (and therefore vim opens additional node instances).

To cope with this, I have setup a key mapping (F8) to only invoke TSSstarthere on the files I want to edit - and not just to the ones I navigate to. In plain words, I don't have TSSstarthere in a 'BufNewFile/BufRead *.ts' event - which means I have to wait for tss to process the file each time I press F8. At least this way I have some control over how many node instances are spawned.

What I wanted to ask is, is there a way to "feed" all the .ts files in a single node instance of tss, and have Vim "speak" to that alone? This would be significantly better for working with my codebase - which numbers in the tens of MBs of typescript code...

Thanks in advance.

[clausreinke]

Hmm.

1. The Vim plugin does not start any servers by itself. Perhaps you've set up an autocommand? It is recommended to call TSSstarthere manually (perhaps by key shortcut) to keep control over the time spent in analyzing large projects.
2. Every large project has a limited number of entry points -ideally, exactly one file- from which all other files in the project are referenced, recursively (this can be a main.ts, or a references.ts, or a files.ts, or something else, so the plugin can't guess it). The idea is to call TSSstarthere only for this main entry point, and any other file in the project that you open in the same editor instance will use the same single nodejs server.

[ttsiodras]

Excellent, that's the missing piece of the puzzle I needed. I created a 'root.ts' one level up from my source folder, via ...

find . -type f -iname \*.ts | \
    while read ANS ; do \
        echo "/// <reference path=\"$ANS\" />" ; done | grep -v root.ts > ./root.ts
    done

...and then invoked F8 on it (which I've mapped to TSSStarthere).

Thank you!

[clausreinke]

just wondering: how do you build your project? Usually, there are either a small number of files passed to tsc or a project file referencing all files. In the former case, both compiler and typescipt-tools recursively find all referenced or imported files, so you might not have to maintain a recursive find yourself.

[ttsiodras]

Usually, there are either a small number of files ...

Ah, well, we are anything BUT usual :-)

ttsiod@avalon ~/GAIA/apps/GAEE2014
$ find . -type f -iname \*.ts | wc -l
1380

ttsiod@avalon ~/GAIA/apps/GAEE2014
$ cat $(find . -type f -iname \*.ts) | wc -c
28744567

We are building extremely complex applications, that traditionally had no right to exist in web space - the kind of enterprise business apps that were built with Oracle forms and ADF/WebLogic. With the advent of AngularJS and TypeScript, these are now finally possible with open, free technologies - and orders of magnitude less network and server load. We are also using code generators, that drive source generation from our own custom ASTs - so we are in many ways stress testing your tools as no one else ever has :-)

In case you are wondering, when fed with :TSSStartHere on the above generated 'root.ts' , the memory use of the node instance spirals to around 1GB of memory, and goes up as we keep doing auto-completion and code navigation using it - if left open for all the day, it ends up around 2.5 GB. In fact, before I left yesterday, I enabled zswap - to ease the pain of my fellow developers! I hope we'll see some help come out of it on Monday :-)

Finally, to answer how we build this huge code base: running a single tsc instance on all of them has been impossible since a couple of months - TSC runs out of memory! I've therefore created a custom build process, using a Makefile and some Python scripting: basically, I detect which .ts files have been modified, and pack them into groups no larger than 1MB - then I pass these groups to concurrently running tsc invocations (make -jN, N being the CPUs/cores in each dev's machine). And I am doing this for both Linux and Windows(CygWin) machines - we have both kinds of dev environments...

Suffice to say, I feel the excitement (and the exhaustion) of Wild West pioneers :-)

Again, thanks for your tools!