Taking JavaScript and .NET to the cloud

Menu

Introduction

After putting aside some time to play around with MeanJS, I wanted to share my thoughts on getting my environment set up for migrating the JavaScript code over to TypeScript.

Get MeanJS running locally

My first task was to make sure I had everything needed to run the MeanJS code as-is from GitHub. I was fortunate to have all the prerequisites installed, including node and MongoDB, but if any further information is needed, the readme provides plenty of help.

To get everything running, I simply ran the following commands in the project’s directory:

$ npm install
$ bower install
$ grunt

If everything went well, you should be greeted with the following page on localhost:3000:

Add type definitions

Now that we know the code works, let’s get started with mixing in some TypeScript. We’ll start by automating the retrieval of type definition files:

Well that didn’t go very well. My suspicion is that the compiler under Visual Studio is doing some strange things which I will need to investigate further. In the meantime, I’ll just use a gulp file similar to one discussed earlier to compile the project… and success!

Conclusion

So we hit a bit of a snag in getting the environment set up. Alongside with the compilation not working under Visual Studio, The IDE was very sluggish with the node project open. Although the node tools are still in beta, it is still quite disappointing considering that Visual Studio is my IDE of choice and would very much like to keep it that way. I will continue to work on this and hopefully come up with some more interesting points for discussion in the future.

Oh, and my first attempts will be up on GitHub as soon as I can make more substantial progress in my migration efforts.

Now that I have spent several weeks looking into TypeScript and the MEAN stack, I have decided to spend the next few weeks to attempt and create a more complete application stack beyond a simple “hello world” application.

After looking at the various MEAN solutions out there, I chose to use MEAN.JS as a basis for the project. This is a popular option with great documentation and a growing community.

My plan from here is:

To convert portions of the server-side code to TypeScript.

To convert portions of the client-side code to TypeScript.

To convert any remaining JavaScript code, such as tests, to TypeScript.

Over the following weeks, I will use this blog to track my progress, but also to share the challenges and topics of interest encountered. The code will be open source and available on GitHub.

This may end up as an interesting proof-of-concept boilerplate application, or as a catastophic mess. Nonetheless, I would not consider the outcome a failure, as the aim is to at gain some further insight in using TypeScript along with Node.js, Angular.js and Express.js. If others will find this journey interesting, then even better!

Introduction

As applications grow in complexity, being able to run automated tests becomes more and more important. In this post, I will go through the basics of writing and running some tests using TypeScript, along with the help of Mocha and Chai. Although this environment can be used to run on node.js and the browser, the focus today will be on the node.js scenario.

Notice how we make our assertions. Chai allows for the standard TDD-style assert, but it also allows the use of BDD styles, which can be more expressive and understandable, especially to those that aren’t concerned with the specifics of the underlying implementation.

Run the tests

After we successfully compile the code, we just need to run the following command:

$ mocha

Doing so will run all the tests that Mocha can find:

Now, let’s make a test fail. We’ll grab the second test and make an expectation that 2+4 would not equal 6:

Conclusion

Today we were able to setup a test environment for TypeScript code, using Mocha as a test runner, along with the BDD-style syntax provided by Chai. This provides a great approach to testing code that resides in node.js applications.

I was out of town over the weekend, so this is going to be a bit of a filler-post. Nonetheless, I wanted to share some links that may be of interest if you want some more information on TypeScript and tools:

Introduction

In previous posts, I have described how definition files can be retrieved via the Definitely Typed website, which leads you to their GitHub repository. This is all well and good if we need to retrieve a small number of definition files, but it can be a hassle if we want to get several definition files.

Automating definition file retrieval

Thankfully, there is a node package that helps retrieve definition files in a more automated way, So let’s go ahead and install this package, known as tsd:

$ npm install -g tsd

Querying definition files

Now that we have tsd installed, we can run queries to see if we can find definition files:

Installing definition files

Let’s go ahead and give it a shot with a definition file. To install the definition file for, say, mongoose, we run the command:

$ tsd query mongoose --action install

If it all goes well we should get the following:

By default, you will find the definition file in typings/mongoose/mongoose.d.ts.

Tracking all installed definition files

We can take this all a step further and create a tsd.json file to track what definitions we have installed. If this route is chosen, it is worth removing all previously installed definition files and proceed in the following manner:

Introduction

As much as I enjoy using Visual Studio, I feel that TypeScript development can be a bit more streamlined. I have investigated various tools to help out, and gulp has caught my eye. Unlike grunt, which was a contender for task automation, gulp allows the creation of automation tasks via code. In this case, we can create such tasks in JavaScript. Although grunt is quite flexible, task automation is achieved via JSON configurations. It may come down to personal preference, and in my case, I chose to dive into gulp.

Today we are going to create a simple script for building and running a typical node.js application written in TypeScript. Let’s get to it.

Install Gulp

You can install gulp via npm:

$ npm install -g gulp

You can also add the following development dependencies in your project’s package.json:

This will install all the packages we will use in our gulpfile. Note that these dependencies will only be installed in a development environment:

gulp: The core gulp package.

gulp-tsc: TypeScript compiler for gulp.js

gulp-shell: command-line interface for gulp.js. Useful for when we want to run the application via gulp.

run-sequence: run a series of tasks in a certain order. For example, build and then run.

Create a gulpfile

For gulp to work properly, we need to define gulpfile.js. Here we can define all sorts of tasks to aid in building and running our application, among other things. Let’s create a basic gulpfile that can handle building and running our application that is written in TypeScript:

build, which compiles the TypeScript code, generating the JavaScript and map files alongside their respective TypeScript files. We can define a different destination for the generated JavaScript, but we will keep it the source and destination directories the same for now.

run, which executes the application.

buildrun, which performs a build, followed by a run.

Running the command “gulp” will build the solution and run it:

You can also run more specific commands like “gulp build”:

and “gulp run”:

All Done!

So we were able to get all some gulp packages together and are able to compile and run a node application that’s been written in TypeScript.

Wait!

Although this file handles a lot of scenarios quite nicely, it’s written in JavaScript. The aim is to get as much as possible written in TypeScript. So let’s keep digging… The extension typescript-require enables the use of require for modules written in TypeScript without needing them to be compiled to JavaScript beforehand. This includes gulpfiles! So we can move all the code from gulpfile.js to gulpfile.ts, and the gulpfile.js would have the following two lines:

require('typescript-require');
require('./gulpfile.ts');

Now we add a reference to the node definition file to our new gulpfile.ts:

/// <reference path='Scripts/typings/node/node.d.ts' />

So without further modifying the actual code, and taking advantage of the fact that TypeScript is a superset of JavaScript and it should work:

Well, that’s not good. After doing a bit of digging, it appears that there’s some kind of problem with the versions of lib.d.ts used in the different packages. Running a local search and sure enough we see a problem:

So let’s replace that with the proper version and… success! Let’s hope typescript-require gets updated soon so this step can be avoided.

After a few modifications, we can have gulpfile.ts be a bit more TypeScript-y:

Conclusion

Today we were able to get everything together to compile and run a node application that’s been written in TypeScript, using gulp instead of the tools provided by Visual Studio. We also took the extra step to get the gulp code, traditionally written in JavaScript, ported over to TypeScript. We now have a solid basis to add more tasks according to the project’s needs.

Introduction

Up until now, we set up the main tools necessary to get TypeScript and the MEAN stack up and running. We got a basic server application running against MongoDB. Today we will dive into the client side, getting a basic front-end written up using AngularJS.

Bower

Similar to npm, bower is a package manager that aids in obtaining packages for use on the front-end. Installation can be done via npm:

$ npm install –g bower

We will create two files to have bower working nicely in our project. The file .bowerrc will allow us to specify where the packages go, and bower.json works in a similar way to package.json, but for bower instead of npm:

Now that we have the packages installed, we need to grab the type definition files for angular, bootstrap and jQuery, since angular has a dependency on jQuery. This is the exact same process described in previous posts.

Updates on the server

Updates on User Controller

The controller on the server needs to be updated to return JSON instead of plain text. We also need a method to retrieve all the users:

Client code

From the client side, we will go ahead and create a page for users and a controller. Angular offers many more things, but again, we are keeping this simple for now, making sure we have basic connectivity and data retrieval out of the way. Later on we will refactor this code and follow established practices.

Let’s go ahead and create the necessary files and folders in the folder public:

The Controller

For the sake of brevity, we will create the User class, the controller and relevant interfaces in a single file in userClientController.ts:

Run the application

Once we run the application, we should be greeted with this simple view:

We can now enter a name and hit the “+” button. The user “angular” should appear on the list.

Let’s check to see what’s happening on the server. Having a look at some node output, we see a post made:

And finally, having a look at what’s in MongoDB:

Great! So we go a (very) basic application working!

Conclusion

Now we have successfully hooked up an application that has a Node/Express back-end, an Angular front-end, and a MongoDB data store. The application itself is very basic, having been used as an opportunity to dig into TypeScript, but is a decent starting point for further investigation. I will continue digging into these concepts, aiming to flesh out the core idea into a more fully-fledged stack for various projects.