TypeScript Module Resolution and requireJs

I have a web project which uses requireJS with TypeScript and the base URL is set as /Scripts. Most Nuget packaged script libraries (jquery, etc.) install the script into /Scripts so I try to keep my own code separate in sub folders.

For example all the scripts used by views are in the /Scripts/Views folder, e.g. /Scripts/Views/Home.ts. Various libraries I have created exist in sub-folders off the script directory: for example my KnockoutJS related code lives in /Scripts/ko and Knockout components in /Scripts/components.

When writing a view script that needs a library you can then reference it thus:
import bindingHandlers = require("ko/bindingHandlers");
All so good so far. However, I also have code in a different folder which is not a sub-folder of Scripts  – and this is where TypeScript breaks down. In versions 1.x it will only walk up the current path to look for modules, and therefore cannot find the libraries.

For example, I have a  folder /Products/Broadband with a script Order.ts If I start this with the require statement require("ko/bindingHandlers"); this fails. TypeScript will look in the current directory, then /Products and finally / – and none of these work.

At present there isn’t a way to fix this short of moving all scripts into the /Scripts folder, but there is a proposed change in TypeScript 2.0 that will support a baseUrl and paths option in tsconfig.json configurations.  This will allow the non-relative module references to resolve correctly.

Advertisements

RIP WD20EADS

I have a HP Microserver N36L edition (one of the first ones) with a couple of 2TB disks mirrored as a backup server. Yesterday one of the drives started to make noises, so after a backup, I checked out what was up.

According to the BIOS RAID utility, the first disk was the failing one, so I removed that. Oddly the AMD RAID controller BIOS utility had no way to repair the array (I could only create or delete). HP’s MicroServer support and downloads page listed a RAID management utility called RAIDXpert (when it actually worked at all), but it was only linked to a page on AMD’s site. This led to a broken link with no downloads. Googling the AMD site for RAIDXpert led to a page with only a PDF instruction manual for RAIDXpert – thanks a lot AMD.

Fortunately more Googling and Softpedia came to the rescue with old copies of the relevant software. Installed and ran; nominated the replacement disk as a spare and the rebuild started. Yay.

The failed disk was a WD20EADS Caviar Green, with a May 2009 date on the label. So it lasted six years – that’s pretty impressive for spinning rust. Checking the SMART data reveals a lot of reallocated sectors, which pretty much what I expected. Interestingly this had a power-on-hours of 49,120. That’s 5.6 years use – almost continual usage since I purchased it.

So a nod to those unsung heroes in the engineering departments of hard disk manufacturers who have created incredibly reliable devices that we so often take for granted.

WSUS update error 80072EE2 solved (at last)

I have a WSUS server set up on my network (with several physical and virtual machines it saves a lot of bandwidth!), but on some systems I was unable to update and constantly had the error code 80072EE2.

If you search on the web you find other people with similar errors. I’d tried various solutions but none worked. Then today I found this useful WSUS client check script. Running this script allows you to check the WSUS-related settings on any machine (even remotely, which is cool and saves a lot of time!).

As soon as I ran this I found the cause of the problem: I had previously used WSUS (about two years ago!) on a different server, and some of the clients had the old server name set as the WSUS server in the registry folder HKLM/SOFTWARE/Policies/Microsoft/Windows/WindowsUpdate – the values for WUServer and WUStatusServer were set to the old server name, which was no longer in existence. A quick change and a long-running problem was solved.