Posted by lee jones on Jul 8, 2016 in JavaScript, WebDev
If you’re writing Node and want to use some of the newer ES6 features then you may have an issue running some of the newer features that haven’t made it into the V8 engine integrated with your specific version of Node. I came across this recently when using the new default parameters feature. Using the latest stable version of node (4.4 at the time of writing), the following code was throwing an error at runtime: function doSomething(param1, param2, callback=()=>{}) { //Do stuff } 123 function doSomething(param1, param2, callback=()=>{}) { //Do stuff} Essentially I wanted the callback parameter to be optional so that I could supply it if I wanted to and it would get invoked, but not throw any errors if not. Using default parameters meant I didn’t have to clutter up my code with lots of null checking and ugly if statements. This is a pattern I use quite a lot in ES6 and feel it leads to much cleaner code. Node was complaining of the unexpected token callback=() as it didn’t understand the assignment of the anonymous function to the callback parameter (i.e. the default value). After a bit of digging it became clear that there were two ways around this problem, both of which worked for me. Initially I sidestepped the issue by using the new harmony feature flags, which turns on the experimental features in unsupported versions of v8. Thus, in my case simply adding the default-parameters flag worked around this problem: node --harmony-default-parameters index.js 1 node --harmony-default-parameters index.js However, the harmony feature flags aren’t really recommended as its putting alpha level code into the fray. The longer term solution (and the route I took) was to upgrade node to the newest version. Again, at the time of writing this is 6.3.0 which has a much, much broader level of ES6 compatibility due to its newer build and newer version of V8. Problem solved. ES6 and...
Read More »
Posted by lee jones on Jun 16, 2015 in JavaScript, Other
I was recently trying to upload a file to a locally developed Node.js API using Fiddler to test some upload functionality. Now uploading a file on its own is trivial in Fiddler, thanks to the ‘Upload file…’ link in the composer window. However, I wanted to add some additional POST data to the request and this stumped me for a while on the exact syntax that fiddler wanted. When you choose a file from the ‘Upload file…’ link you’ll notice that fiddler replaces your body content with something similar to the following: ---------------------------acebdf13572468 Content-Disposition: form-data; name="fieldNameHere"; filename="Panthera.jpg" Content-Type: image/jpeg <@INCLUDE *C:\Users\leejones\Pictures\Panthera.jpg*@> ---------------------------acebdf13572468— 123456 ---------------------------acebdf13572468Content-Disposition: form-data; name="fieldNameHere"; filename="Panthera.jpg"Content-Type: image/jpeg <@INCLUDE *C:\Users\leejones\Pictures\Panthera.jpg*@>---------------------------acebdf13572468— I tried all combinations of prepending and appending form data but my node.js app was receiving none of it. Eventually I stumbled on the solution which is not at all obvious. You need to repeat the Content-Disposition sections for each form field you want to upload: ---------------------------acebdf13572468 Content-Disposition: form-data; name="field1"; value ---------------------------acebdf13572468 Content-Disposition: form-data; name="field2"; value2 ---------------------------acebdf13572468 Content-Disposition: form-data; name="fieldNameHere"; filename="Panthera.jpg" Content-Type: image/jpeg <@INCLUDE *C:\Users\leejones\Pictures\Panthera.jpg*@> ---------------------------acebdf13572468— 123456789101112 ---------------------------acebdf13572468Content-Disposition: form-data; name="field1"; value---------------------------acebdf13572468Content-Disposition: form-data; name="field2"; value2---------------------------acebdf13572468Content-Disposition: form-data; name="fieldNameHere"; filename="Panthera.jpg"Content-Type: image/jpeg <@INCLUDE *C:\Users\leejones\Pictures\Panthera.jpg*@>---------------------------acebdf13572468— The other thing I forgot to do was change the automatically generated name=”fieldNameHere” to the actual parameter name that my node.js app was expecting. Once these niggles had been fixed, it worked like a...
Read More »
Posted by lee jones on May 20, 2015 in JavaScript
If you’re planning to play about with Grunt on Windows any time soon, chances are you’ll find a tutorial online which tells you to install grunt globally as follows: npm install –g grunt 1 npm install –g grunt This will run just fine, but when you next run grunt you’ll get the lovely error: 'grunt' is not recognized as an internal or external command 1 'grunt' is not recognized as an internal or external command Whats going on here then? Turns out Grunt itself is no longer installed globally, but its command line interface (CLI) is. The CLI is simply there as a GLOBAL means of launching a locally provisioned grunt. Therefore all you need to do is amend the command to: npm install –save-dev grunt npm install –g grunt-cli 12 npm install –save-dev gruntnpm install –g grunt-cli that way, the next time you run grunt <anytask> 1 grunt <anytask> from the command line, the CLI will invoke the locally installed grunt instance and you should be good to go. If in doubt, just follow the official grunt.js getting started...
Read More »
Posted by lee jones on Aug 11, 2014 in JavaScript
I recently ran into a problem whereby when attempting to use session-mongoose for session storage via MongoDB in a Node.js application, I was being hit with the error: connection.session.store cannot read property of undefined 1 connection.session.store cannot read property of undefined After Googling this with Bing and some other search engine jiggery-pokery I came up blank. Lots of references from a few years back which were down to a number of factors, but nothing relevant to my particular error. Looking at my code: var MongoSessionStore = require('session-mongoose')(session); var sessionStore = new MongoSessionStore({ url: credentials.mongo.development.connectionString }); app.use(require('express-session')({ store: sessionStore })); 12345 var MongoSessionStore = require('session-mongoose')(session); var sessionStore = new MongoSessionStore({ url: credentials.mongo.development.connectionString }); app.use(require('express-session')({ store: sessionStore })); And looking at the Github page for session mongoose there was nothing obviously wrong with what I was doing. Thus I started poking around in the node_modules folder to try and find out what is going on. It turns out that as Express and Connect have been largely decoupled, the Session middleware I no longer party of the connect object. However, session-mongoose hasn’t been updated to reflect this and thus it was still referencing connect.session.store. The Session object is no longer a property on the connect middleware, so the simple fix was to change the passed in parameter to session-mongoose function to connect.Store (/node_modules/session-mongoose/index.js:266). As is often the case, Node.js is still a very immature technology and the rate of change if its components and add-ins continues to cause compatibility and dependency problems, despite the best efforts of NPM. ...
Read More »
Posted by lee jones on May 22, 2014 in JavaScript
I was recently playing with a node.js and Express application and ran into a small issue that wouldn’t let me render any templated content to the client. The issue was presenting itself in a number of ways, firstly: The first error I was getting was: app.configure(function() { ^ TypeError: Object function (req, res, next) { app.handle(req, res, next); } has no method ‘configure’ If you look online for express documentation, most will be using the app.configure syntax. However, as of version 4.0.0 of express, the app.configure method has been removed. See here (these release notes) for more detail. Looking in my package.json file I had the dependency for express set to latest: JavaScript "dependencies": { "express": "latest", "jade": "~1.3.1" } 1234 "dependencies": {"express": "latest","jade": "~1.3.1"} This is inherently dangerous for this very reason. As node and express are evolving so quickly, the likelihood of breaking changes between versions is great. The quick fix for me was to enforce an older (compatible) version that I know worked with the rest of the app: JavaScript "dependencies": { "express": "3.4.0", "jade": "~1.3.1" } 1234 "dependencies": {"express": "3.4.0","jade": "~1.3.1"} Then, once I rolled back the version of express (this is only a test app – the forward thinking thing to do would be fix the now obsolete code!) I started getting the following error: Error: No default engine was specified and no extension was provided This is strange as I clearly had specified a view engine: JavaScript app.configure(function () { app.set('view engine', 'jade'); app.set('views', __dirname + 'srv/views/'); }); 1234 app.configure(function () {app.set('view engine', 'jade');app.set('views', __dirname + 'srv/views/');}); After searching online and reading lots of solutions (most related back to daft errors like this transpired), I started to doubt the validity of the error message. Turns out that it was in fact the path to the views folder that was failing and it was nothing to do with the view engine (jade) at all. A quick fix to the path and everything started working: JavaScript app.configure(function () { app.set('view engine', 'jade'); app.set('views', __dirname + '/srv/views'); }); 1234 app.configure(function () {app.set('view engine', 'jade');app.set('views', __dirname + '/srv/views');}); The simplest mistakes often cause the biggest headaches. Despite its rapid change/release cycle and constantly battling with new versions and breaking changes, I do love the ‘bare metal’ feel of programming in...
Read More »
I'm a gadget loving code-junkie who loves to program, create websites and try out new stuff. Married, with two young daughters I am also a keen marathon runner and fitness enthusiast.