Including Local Files in Compiled TypeScript

When working with TypeScript I like to separate my code into files and folders for the sake of maintainability, cleanliness and organisation.

However as someone new to the language I had a bit of trouble getting those files working together and compiling as I expected. Some search results confused me with the use of the import keyword and it all seemed more complicated than such a simple task should be – they involved including other scripts to handle asynchronous loading and dependency handling, etcetera…

I’m talking about local files that you just want to be included in compilation – not external modules or something to be lazy loaded, so of course it should be very simple. Once I found out I thought I’d post it here as a nice, simple reference for anybody who may bump into the same problem.


If you want TypeScript use file foo.ts in another file called main.ts, just include a reference at the top of main.ts like this:

///<reference path="foo.ts"/>

Now foo.ts will be compiled to a separate foo.js file. TypeScript can now compile main.ts as though foo.ts was loaded beforehand, but you still need to load it yourself:

<script src="foo.js"></script>
<script src="main.js"></script>

I personally expected the referenced file to be compiled into main.js so I’d only need to use one script tag and, more importantly, so my HTML wouldn’t be dependent on the file structure I used behind the scenes.

To meet this expectation, explicitly specify main.js as the output file when compiling:

tsc [--watch] --out main.js main.ts

Automagic WordPress Plugin Deployment with Codeship

WordPress plugin development is succinct and powerful. Other than the plugin descriptor and a README, you can jump right into writing problem solving code.

Useful plugins with only one line of (non-comment) code exist and are in circulation, like Disable XML-RPC which has hundreds of thousands of downloads.

So it’s all fantastic, but if you want those downloads you’ll probably need to get your code into the WordPress plugin repository, and there’s a speed bump there:

WordPress forces us to use SVN and a specific directory structure to deploy to their repository.

As a Git user, I hate the idea of having to commit and push, then pull or copy the files into another couple of directories (yep, duplication…), and commit and push again, every time I want to deploy an update. I’ll also have to figure out SVN commands that I’m not familiar with and clone two repositories to get to work in a new environment. Redundancy sucks.

Enter Codeship: a plug ‘n’ play testing and deployment solution which doesn’t impose any changes to your environment or deployment process.

The only assumption is that you’re using Git (they may support other VCSs, you should check).

Pushing to master (or a branch of your choice) is deploying to the WordPress plugin repository.

Brilliantly elegant, automagic WordPress plugin deployment.

Codeship has preset deployment configurations so you can just fill in the blanks (i.e. for Heroku), but the WordPress plugin repository is not one of them. That being said, I had little trouble using their custom script functionality to get the job done, and that’s what this guide will take you through.

Edit: this guide has undergone a breaking change on 2015/08/30. If you worked through it around this time or up to a month earlier, consider going through it again to ensure smooth operation. It particularly regards the assumed directory structure, and involves a change in the deployment script.

Continue reading “Automagic WordPress Plugin Deployment with Codeship”

Production-ready Cloud9 + WordPress Development

Hopefully you, like many, are using or have at least tried Cloud9. If you have, you’ve probably liked it and thought it was pretty nifty, but maybe are not yet prepared to use it for developing a serious project and migrating the result to production from there.

If you haven’t tried C9, then you may want to consider doing so. It’s a very handy tool that you can use for just about all forms of web development, and it’s been getting better and better. It is not only the epitome of convenience, but also something that I believe will help us all become more “adaptive” developers. We’ll be able to set up environments and get comfortable quickly instead of having to configure our own computer which will one day be reformatted or replaced.

Convenience and theoretical personal enrichment aside, can we use C9 for serious?

I was tasked with coming to a conclusion on whether to trust C9 for a not-exactly-multisite WordPress development in my office. I was to make sure that everything we’d need to do could be done simply before I gave it the all clear.

I’ve recorded some noteworthies and solutions to necessary non-trivial tasks below.

Continue reading “Production-ready Cloud9 + WordPress Development”