What's New In ExpressJS 5.0

John Kariuki
๐Ÿ‘๏ธ 20,577 views
๐Ÿ’ฌ comments

Express 5.0 is currently in the alpha release stage and it will not be quite different from Express 4. While the underlying API remains the same as that of Express 4, you may need to watch for some deprecated methods that may break your application when you upgrade.

It should, however, be a smooth transition between Express v4 and Express v5 as we will see in the following examples.

We've built APIs on Express 4, so we're very excited to see that 5 is coming shortly

Table of Contents

    Setting Up An Express 5 Project

    To get started, set up a new node project with npm init and install the latest Express 5 alpha release from npmjs. You can always refer to the release logs from the Express repository's history.md file.

    $ npm install express@5.0.0-alpha.3 --save

    We are now ready to see some of the changes. Most of the methods and properties that we will look at here were previously deprecated and have been completely removed in Express 5.

    Deprecated Methods And Properties

    app.del()

    app.del() has been removed as a HTTP DELETE registration method in favor of app.delete().

    app.del('/resource', (req, res) => res.send('deleted'));
    //4: express deprecated app.del: Use app.delete instead
    //5: TypeError: app.del is not a function

    app.param(fn)

    The app.param(fn) signature was used for modifying the behavior of the app.param(name, fn) function. It has been deprecated since v4.11.0, and Express 5 no longer supports it at all.

    req.param(name)

    You can no longer access request parameters using the param method. Instead, use the req.params, req.body, or req.query objects.

    // Bad
    app.get('/users/:id', (req, res) => {
        res.send(User.find(req.param('id')));
    });
    //4: express deprecated req.param(name): Use req.params, req.body, or req.query instead
    //5: TypeError: req.param is not a function
    
    // Good
    app.get('/user/:id', (req, res) => {
        res.send(User.find(req.params.id));
    });

    Pluralized Method Names

    The following methods have been pluralized in Express 5:

    • req.acceptsCharset() is replaced by req.acceptsCharsets().
    • req.acceptsEncoding() is replaced by req.acceptsEncodings().
    • req.acceptsLanguage() is replaced by req.acceptsLanguages().

    Camel-Cased methods

    The res.sendfile() function has been replaced by a camel-cased version res.sendFile().

    Status Code Chaining in Responses

    res.json(obj, status)

    Express 5 no longer supports the signature res.json(obj, status). Instead, set the status and then chain it to the res.json() method like:

    res.status(status).json(obj)

    res.jsonp(obj, status)

    Express 5 no longer supports the signature res.jsonp(obj, status). Instead, set the status and then chain it to the res.jsonp() method like:

    res.status(status).jsonp(obj)

    res.send(body, status)

    Express 5 no longer supports the signature res.send(obj, status). Instead, set the status and then chain it to the res.send() method like:

    res.status(status).send(obj)

    Leading colon (:) in name for app.param(name, fn)

    If your first experience with the micro framework was Express 4, you probably have no idea what this is all about.

    A leading colon character (:) in the name for the app.param(name, fn) function is a remnant of Express 3, and for the sake of backwards compatibility, Express 4 supported it with a deprecation notice. Express 5 will silently ignore it and use the name parameter without prefixing it with a colon.

    This should not affect your code if you follow the Express 4 documentation of app.param, as it makes no mention of the leading colon.

    Let's Talk about res.send(status)

    In Express 4, res.send(status) where status is a number was deprecated as a way of setting the HTTP status code header in favor of res.sendStatus(statusCode).

    app.get('/', (req, res) => {
        res.send(500);
    });
    // 4: express deprecated res.send(status): Use res.sendStatus(status) instead

    This is the expected response in express 4 (500 Internal Server Error)

    $ http :8001
    HTTP/1.1 500 Internal Server Error
    Connection: keep-alive
    Content-Length: 21
    Content-Type: text/plain; charset=utf-8
    Date: Wed, 08 Feb 2017 12:01:48 GMT
    ETag: W/"15-3JQVFLwoG6yepWGqlDPA/A"
    X-Powered-By: Express
    
    Internal Server Error

    The same code would return the exact opposite in express 5 (200 status code with '500' message).

    $ http :8000
    HTTP/1.1 200 OK
    Connection: keep-alive
    Content-Length: 3
    Content-Type: application/json; charset=utf-8
    Date: Wed, 08 Feb 2017 12:04:22 GMT
    ETag: W/"3-zuYxEhwuySMvOi8CitXImw"
    X-Powered-By: Express
    
    500

    Express 5 no longer supports the signature res.send(status), where status is a number. Instead, use the res.sendStatus(statusCode) function, which sets the HTTP response header status code and sends the text version of the code: โ€œNot Foundโ€, โ€œInternal Server Errorโ€, and so on.

    If you need to send a number by using the res.send() function, quote the number to convert it to a string, so that Express does not interpret it as an attempt to use the unsupported old signature.

    Changes And Improvements

    app.router

    The app.router object, which was removed in Express 4, has made a comeback in Express 5. In the new version, this object is a just a reference to the base Express router, unlike in Express 3, where an app had to explicitly load it.

    req.host

    In Express 4, the req.host function incorrectly stripped off the port number if it was present. In Express 5 the port number is maintained.

    app.get('/', (req, res) => {
       res.status(200).send(req.host);
    });
    // 4: localhost
    // 5: localhost:8000

    req.query

    In Express 4.7 and Express 5 onwards, the query parser option can accept false to disable query string parsing when you want to use your own function for query string parsing logic.

    res.render()

    This method now enforces asynchronous behavior for all view engines, avoiding bugs caused by view engines that had a synchronous implementation and that violated the recommended interface.

    Read more about this in this Express Github issue.

    Proposed Changes in the Near Future

    Middleware Promises

    Promises have become quite popular in asynchronous development and it's been proposed that next() returns a promise so that middleware can be resolved and propagated through the next method.

    This is how that would look like.

    app.use(function (req, res, next) {
      // a promise must be returned, 
      // otherwise the function will be assumed to be synchronous
      return User.get(req.session.userid).then(function (user) {
        req.user = user
      })
      .then(next) // execute all downstream middleware
      .then(function () {
        // send a response after all downstream middleware have executed
        // this is equivalent to koa's "upstream"
        res.send(user)
      })
    })

    Conclusion

    Express 5 is still in alpha so there are bound to be changes. I will keep updating this post as the updates are rolled out. Take a look at this pull request if you want to see an updated list of changes for release.

    John Kariuki

    22 posts

    Software developer at Andela.

    PHP, JavaScript developer (AngularJS, React, Node.JS)

    Avid blog reader and fascinated by drones.

    I play basketball, swim and jog in my free time.