Allen Conway's .NET Weblog

Exploring all things .NET and beyond...

Chutzpah and non-ES5 JavaScript for Unit Testing is Problematic

I've been working with Chutzpah for VS.NET as a test runner for my Jasmine JavaScript unit tests and ran into some issues that had me essentially stuck and running out of debugging options. I mined Matthew Manela's samples, GitHub repo, articles, log tracing, settings files, simple test harnesses, and many other trial and error event before finally determining the root cause of my headaches.

No matter how simple it seemed of a test harness I used in JavaScript to test using Chutzpah, I kept getting errors like the following: 
Can't find variable: myVariable in file xyz....
Normally this is an indication that the referenced JavaScript file is not properly referenced and the test cannot use it. Therefore the test fails and complains that a variable can't be resolved because ultimately the file is not referenced or not referenced properly. Or so it appears on the surface.

This is the red herring...



This led me on a path of vigorous path tracing, trying different path notation for referencing, using chutzpah.json files, running from the command line, debugging, refactoring, and on and on. No matter what I'd do I couldn't apparently get the file referenced for the unit test to run.

Naturally what makes this all worse was that if I open my JS tests in the browser using the default Jasmine Test Runner, they of course pass. So I know it's only a problem with Chutzpah running my tests.

I do the most basic of tests:

expect(true).toBeTruthy();

This passes. So at least I know VS.NET and Chutzpah can actually work together. 

Here is the crux of it and I'm not sure why it dawned on me but I decided to investigate my JS code. I had begun to sprinkle in some ES6 syntax that by now was compatible in most current browsers. Things like 'class' or 'for...of' loops. The problem is Chutzpah uses the PhantomJS headless browser to run the unit tests. It is based off the WebKit layout engine, so its about like running tests in Safari.

However I was completely wrong in this assumption. From the following (albeit an older package the reference still holds for this topic): 
"Most versions of PhantomJS do not support ES5, let alone ES6. This meant that you got all sorts of errors when you tried to test ES6 features, even if you had used the Babel/6to5 transpiler."
PhantomJS today appears strictly ES5 compliant and even a single line of ES6 syntax in your JS file will cause the referenced file not to be processed and thus serving up the error that it cannot be found. It can't be found because it can't be understood by PhantomJS. Hence the red herring about not being able to understand a variable being referenced in my test because the JS class could not be used.

I had one particular JS class I thought was 100% ES5 and this made the debugging even worse. The way I finally sniffed out some ES6 syntax was to drop it in a TypeScript file and target it to transpile to ES5 JS. When I compared the files side-by-side sure enough I found some ES6 syntax in my JS files. Once I ported the ES5 compliant JS over, Chutzpah and PhantomJS both worked perfectly and my tests passed within VS.NET.

I think the lessons learned here are the following:
  • PhantomJS which Chutzpah uses to run unit tests requires ES5 only JS, so make sure all of your JS is ES5 transpiled (Babel, TypeScript, etc.) and target these source files for the unit tests
  • If able to write and target ES6 features and browsers and not wanting to transpile to ES5 compliant JS, consider using a different JS Test Runner than Chutzpah.

NuGet Package Source Blank After VS.NET Update

I recently updated VS.NET 2015 to Update 2 which was just released, but hit a snag with NuGet. Upon opening VS.NET and trying to download NuGet packages, I kept getting errors that the package didn't exist. I noticed the "Package source" dropdown was blank and had no selectable values. Even if I went to the VS.NET options for NuGet, I could no longer see the default nuget.org package source configured. Something must of went awry during the VS.NET update.

Thanks to a nudge from this Connect report, the recommendation was to update the NuGet package manager from the 'Extension and Updates' menu. Sure enough there was an update, and after installing and restarting VS.NET, the "Package source' values were once again populated with nuget.org and I could download packages.


I'll be Speaking at VSLive! Austin - Discount Code to Attend


I’ll be speaking at Visual Studio Live!, May 16-19 in Austin. Surrounded by your fellow industry professionals, Visual Studio Live! provides you with immediately usable training and education that will keep you relevant in the workforce.

I’ll be presenting the following sessions:
SPECIAL OFFER: As a speaker, I can extend $400 savings on the 4-day package. Use offer code AUSPK08 or register using the link here: http://bit.ly/AUSPK08_Home

Amplify your knowledge at Visual Studio Live! Austin — bring the issues that keep you up at night and prepare to leave this event with the answers, guidance and training you need.  Register now: http://bit.ly/AUSPK08_REG

Why is the tsconfig.json file not copying my TypeScript files to wwwroot?

If you've been looking into ASP.NET 5 (eventually .NET Core 1.0) and working with TypeScript you'll notice things are very different than when using older versions of ASP.NET. Specifically the need to configure your TyoeScript virtual project using a tsconfig.json file.

Within the file you'll need to add a line such as the following to indicate where the transpiled .js files will be copied in wwwroot:

"outDir": "../wwwroot/appScripts",

The source directory has a documented convention though (at least at the time of this entry) that could be easily overlooked. I found the information on this GitHub thread. The tsconfig.json file will only check for TypeScript files in the scripts folder. Therefore you must have your tsconfig.json file within the /scripts folder in order for the outdir value and ultimately copying of files to work.


Fixing a npm Package That Will Not Reinstall


Recently when working on an Angular 2 app in VS.NET 2015 using an ASP.NET 5 template I began to see build errors that Angular 2 was missing. 



I was having trouble getting Angular to reinstall no matter which version I selected in my package.json file. It didn't matter if I deleted the local files or npm cache as nothing would work.

Upon inspecting the output I noticed the following errors:


npm ERR! error rolling back  errno: 10,
npm ERR! error rolling back  code: 'EBUSY',



Upon further research and some nudging from the problem on this GitHub link, it appeared a file was locked. The answer -> reboot the Windows machine. This does appear to be a Windows issue with file locking of some file(s) within the npm package and causing the error.

Upon reboot, I right-clicked 'Dependencies' and selected, 'Restore Packages.' Sure enough the Angular 2 npm package reinstalled successfully. Previously the angular2 folder existed but there was nothing inside of it. If you ever have any issues getting a npm package to install, always make sure to read the output in the VS.NET console to shed light on any issues.



Is Aurelia going to a realistic competitor?

The quick and legitimate answer to the title of this post is, "I don't know." However I wanted to do a little digging to see the potential for this relative newbie to the JS Framework arena that is already so competitive and overflowing. Just see this: 100+ JavaScript Frameworks For Web Developers

To provide some context, here is a visual from Google trends based on some of the major competing frameworks (note: no matter which combination of 'aurelia' I used the results were all the same). Even if this metric isn't perfect, it still provides some level of comparison for popularity:



This GitHub thread has some interesting comments from Rob Eisenberg over this past year on Aurelia. With all the talk of it being a competitor to JavaScript frameworks like React and Angular, I was curious about its backing and support. With those frameworks you have Facebook and Google respectively behind them. I was curious if Aurelia was just a bunch of devs revolting with a new framework out of angst for what happened with the lack of use for Durandal and the ill advised direction Angular 2.0 was going according to Rob, or in the long run would this be a serious contender.

It's no secret JS frameworks and libraries seem to come and go as do the seasons, and investing heavily in one is an important decision. Durandal seemed to have lost a flame quickly in this JS framework battle, so I'm curious how Aurelia will fare.

Here are some quotes from that link from Rob:
"From a business perspective, Aurelia is backed by Durandal, Inc. Durandal is a company that is dedicated to providing open, free and commercial tools/services for developers and businesses that create software using web technologies."
As a private company it is tough to see the backing or possible angel investors involved with Durandal. However for OSS with a passionate community this could be a moot point.

He does go on to mention:
"Durandal is positioned to begin raising Series A venture capital this month. That isn't to support the open source Aurelia project. That project does not need funding. Rather, it is to support Durandal Inc. which intends to offer a much richer set of tooling and services for those who want to leverage Aurelia and the web. We are building out a serious business and our entire platform will be built with Aurelia and for Aurelia. Our potential investors are very excited about our plans and we expect to have some cool stuff to show in the future"
So that could add some potential to Durandal Inc. to keep this thing moving forward. He continues on about the horsepower behind it's actual creation and continued development:
"Aurelia itself is solid due to the fact that it currently has a 12 person development team distributed throughout the world and a large active community, especially considering it was only announced a couple of months ago"
...a bit later he quotes:
"We have 17 members on our core team currently which contribute daily"
Well hopefully those 12-17 people remain passionate :D

I think the conservative decision today is to go with ReactJS or AngularJS with Aurelia being the bold one. I'm not thinking it's going to fade away anytime soon, but with so many competing frameworks it's important for it to catch some mainstream traction or the OSS community might loose steam working for a lost cause.

I for one hope it does succeed and becomes a bit more mainstream. When comparing the syntax for ReactJS, Angular 2.0, and Aurelia, I believe I'd choose Aurelia. Unfortunately for me I'm one in the camp that actually likes Angular 1.x and it's implementation so I don't really have any gripes to it currently for switching to something different. However its shortcomings in performance and implementation are certainly going to be addressed by the radically different 2.0 which still needs to grow on me a bit.

Time will tell and the community not I will answer this question by adoption (or lack thereof) of this framework and others in the upcoming months and years.

Git Ignore to Untrack TypeScript Auto Generated Files

When using TypeScript you really don't want the transpiled output files created from the source .ts file to be committed to the repository. This is because the output could be looked at analogous to the /bin generated files which we all know are not to be committed. The TypeScript auto-generated files (.js and .js.map) will be built independently for each user's source, and only the single .ts file should be committed. 

The only exception I see to this process is if there is a restriction on TypeScript compiling on the server (i.e. CI build server) in which case the actual .js file might have to be committed. As long as the TypeScript compiler is present for compilation, only the .ts file should be committed.

To ignore the auto-generated .js and .js.map files for a new project the process is quite simple. Just add some rules to the .gitignore file at the root of your project like below and these files will not be tracked.

# Typescript Auto-generated files
# Note: all files must be TS files in this directory or ordinary JS files could be removed
# Modify as needed to preserve files and be more explicit
BowlingSPAWeb/BowlingSPA/app/*.js
BowlingSPAWeb/BowlingSPA/app/*.js.map
BowlingSPAWeb/BowlingSPA/app/controllers/*.js
BowlingSPAWeb/BowlingSPA/app/controllers/*.js.map
BowlingSPAWeb/BowlingSPA/app/services/*.js
BowlingSPAWeb/BowlingSPA/app/services/*.js.map

The above still needs to be done for existing projects, but if you see tracked changes already showing up for your repository, you are going to have to manually remove them from being tracked since they are already a part of the repository. From the Git docs:
If you already have a file checked in, and you want to ignore it, Git will not ignore the file if you add a rule later. In those cases, you must untrack the file first.
The easiest way to do this is to run the following command against the applicable files using Git Bash commands. I find opening the Git Bash command prompt directly from the directories makes this process easiest.

git rm --cached myfile.js
git rm --cached *.js
git rm --cached *.js.map

You may prefer instead of using wildcards (like above) to manually address each file individually applying the command. It's a 1 time deal to remove the tracking, so it might be best to be explicit as I did it below:


Note, once successfully removed, you can't run the command again or you will get an error message similar to the following:
fatal: pathpec 'myfile.js' did not match any files
This is because the file has already been removed from the repositories tracking so there isn't any command to preform against it.

If using VS.NET, you should see after refreshing that these files are now shown as being deleted from the repository. 





I do recommend that you commit from the Git Bash command line when removing these files. I had mixed results when jumping over to VS.NET to commit, as the deleted files were not shown as changes to the master to be synced to the server. Only once I committed from Git Bash did it actually apply and commit successfully:


After committing and on subsequent updates, the changes to the TypeScript auto-generated files should no longer be tracked and shown as 'Included Changes'