Monthly Archives: April 2016


Aurelia error: TypeError – customConfig.configure is not a function

When manually adding a custom bootstrap class – the main.js entrypoint if you will – I suddenly stumbled upon the following error message in the console:

TypeError: customConfig.configure is not a function(…)

I found the resolution in a (closed) issue on GitHub, where it is stated that it is not required to specify the aurelia-app attribute, if you use a configuration to set the main entry point for your Aurelia application.

In the aforementioned GitHub issue it is pointed out specifically when you use WebPack, but even with the default starter pack (which uses config.js) this occurs as well.

It’s quite easy to fix. Simply change the following:

<body aurelia-app="main">

… into this simpler signature where you remove the explicit entrypoint “main”:

<body aurelia-app>

And you’re good to go. This of course assumes you have a specific configuration with your web bundler, like for example the config.js from the starter kit, where it should state what exactly is your app’s entry point:



Error: zsh command not found

I encountered this error message on one specific macOS system, where not all NPM packages that are installed globally (and successfully I might add) were available from the command line. In my case, a simple npm install -g jspm, to install the JSPM’s CLI, would result in the following error message:

➜ ~ jspm -v zsh: command not found: jspm

My first thought was to “blame” JSPM. Especially considering other NPM packages were available just fine from the command line. After some digging around it seemed related to something in my PATH variable.

By default, on macOS and when you’ve installed NPM using Homebrew, the default path should be /usr/local. To verify this, simply use:

$ npm config get prefix

If the output doesn’t match the earlier mentioned /usr/local path, like in my case where it was set to /Users/jhanssens/.npm-global/lib, simply change it accordingly:

$ npm config set prefix /usr/local

Hiding .js and .map files in Visual Studio Code, when in a TypeScript project

When you are working with TypeScript in Visual Studio Code, you often don’t want to see generated JavaScript files and source maps in the explorer or in search results. I mean, this can get messy:


Look at all those bloated .js and files which clutter my otherwise perfectly clean file explorer. Yuck!

Luckily, there is a way to hide derived Javascript files in VS Code out of the box. Using a filter expression, we can use the files.exclude setting to hide these derived files.

Simply start by navigating to: Code > Preferences > Workspace Settings

Next, in the right pane you’ll see the settings.json override file, where you can add the following:

// place your settings in this file to overwrite default and user settings.
    "files.exclude": {
        // include the defaults from VS Code
        "**/.git": true,
        "**/.DS_Store": true,

        // exclude .js and files, when in a TypeScript project
        "**/*.js": { "when": "$(basename).ts"},
        "**/*": true

This will match on any JavaScript file (**/*.js), but only if a sibling TypeScript file with the same name is present. Of course the exclude of * will hide all appropriate map files. With a result that the file explorer will no longer show derived resources for JavaScript if they are compiled to the same location.