TypeScript: Setting up an IDE and working environment

This episode is pretty straight forward: configuring the workspace. My IDE choice is either Sublime Text or IntelliJ IDEA and I’m focusing on these two. Additionally, I’ve setup the working environment, auto reloading the browser (as the ultimate runtime environment of my JavaScript experimentations).

TypeScript can be installed through the NPM package manager npm install -g typescript.

Wait. What? What is npm. So here we go; welcome to the world of JavaScript package managers. npm stands for package manager for node.js (one among many). I won’t be drilling node installation details - not worth it. I’ll just point out one thing which saved my live millions of times: always use version managers. It’s a great practice from PHP Pear times, where everything was global, thus changing a library version for a single project was close to impossible.

Now we can bound not only libraries but whole runtimes (compilers) and avoid any interference between runtimes. Things like rvm.io, Virtualenv, phpfarm saved tons of developers' hours. Same story applies to the node world and I suggest not going forward without installing one of many version managers. I went with nvm. If you ask why - probably it had highest number of Github stars ;-)

Which node and npm on board, typescript installation is a piece of cake. Having successfully done that I could’ve moved forward.

For Sublime, Microsoft helps with an official plugin. If the node is already installed and enabled - installation is easy and out of the box.

The editor comes with syntax highlighting and preconfigured compilation (upon request). In general - enough to move forward.

There is well documented TypeScript support for IntelliJ IDEA, which can be installed from the JetBrains plugin repository. Obviously it required node to be installed and enabled.

I’ve installed the plugin, but I’ve disabled the compiler (the checkbox 'Enable TypeScript Compiler'). As described in in the previous part I "embedded the transpiler" into the browser and evaluated the *.ts files directly. How the plugin worked for me was syntax colouring and hints. Additionally I could have made my IDE generate JavaScript files together with the sourcemaps (for both IDEA as well as Sublime Text), but I felt it a bit unnatural, too tightly coupled to the IDE. That was something to avoid, to be solved by the build scripts directly on my CI server. Later on.

Final piece of the puzzle was to save hassle of hideous pressing F5 or Ctrl+R for refresh. There’s where Livereload kicks in.

Livereload "ships" in two pieces: browser (page) extension, that triggers a page reload and a file system watcher - to notify changes in the HTML, CSS, image files (like whatever file extension is configured) - that something needs to be reloaded.

The browser part can be handled by a plugin or browser extension or a snippet embedded to the page. The <script> is required for Safari users, due to Safari API limitations; extensions cannot for with file:// URL. The snippet allows localhost communication, but livereload works also for mobile (on device) browsers (simulators) - with a specific IP address provided inline.

Livereload is an open protocol so the "server" side comes in many different flavours, for the developers' convenience. For me, as a JVM-mostly developer, some Java based build tools were the first choice. But there is no need to limit oneself to only Gradle livereload plugin or Maven. Livereload works perfectly with node, python, ruby (rake) etc.

1. This is the folder where the reloadable content sits.

This however brings some limitations. As I use vanilla TypeScript and do an in-browser transpilation - that involves additional AJAX calls by the transpiler.js script. When the protocol is set to file:// some browsers forbid it for security reasons (like Chrome) some don’t really care (hello Firefox).

For browsers like Chrome we need to expose our content as a basic HTTP server. For me, the simplest HTTP static server from the previous part (php -S localhost:8080 -t {docRoot}) did the trick. I know I could have taken some basic HTTP server from node world (like express) and wrap everything in typical JavaScript stack. That will work as well, but my intention so far is to minimize elements not natural (unknown and unfamiliar) for a typical JVM developer. I’ll get to the nodemon later.

This set-up has taken me few steps forward in both understanding how the JS oriented environment might work as well as with grasping the JavaScript goodies on their own. Hope this will work for you as well.