Posts tagged with "#nodejs"

I have some side projects that don’t see much traffic so I run them on a 5$ digital ocean droplet running Dokku.

Dokku is an open source Heroku-like platform. It’s super easy to create and maintain multiple applications on a Dokku instance. It’s perfect for solo makers.

There are plugins for most of the common services you might want like PostgreSQL or Redis.

Here’s what we’re going to do

1. A Brief overview of Dokku
2. How to get a Dokku instance running
3. Create a new Dokku application
4. Add a database service
5. Expose the database for debugging and testing (Optional)
6. Add a domain to the application
7. Add any configuration variables for your application
8. Add SSL to the application
9. Add the Dokku remote to your application
10. Push your application to Dokku
11. Maintaining your Dokku server

When you have to login to npm for multiple organisations it can be easier to use an .npmrc file that you move around rather than npm login command.

If you want to use semantic versioning and automate release versions using semantic-release for your front-end client application you probably don’t want to actually publish it to npm.

Here is how to use semantic-release while not releasing to npm.

ECMAScript modules are the official standard format to package JavaScript code for reuse in the future. Es6 modules now have full support in Node.js 12 and above so it’s time to start using them.

JavaScript developers and node libraries have typically used commonjs for modules up to now. If you’ve used typescript in the past few years you will be familiar with the module import syntax in you application. Instead of commonjs require("module") most typescript applications use some variation of import module from "module".

Typescript will then transpile this import syntax into commonjs require statements for you. This step is not necessary in modern Node.js applications. You can just use import module from "module" directly in your transpiled code.

If you use typescript you can change just change your tsconfig settings to output ECMAScript es6 modules and you will be good to go. If you don’t use typescript you might have to do some rewriting if you want to get your app updated.

Here are solutions to the issues that took me a bit of time and investigation to figure out when I was upgrading my Node.js application to use ECMAScript modules like configuring typescript, setting up jest, configuring the package.json correctly and more.

Using Eslint in your project is an easy way to improve productivity and reduce low-value, subjective code-style comments from pull requests. It will make your code consistent and easy for the next developer to read and we should always be optimising for readability.

Using some specific Eslint plugins will also prevent real bugs and security issues in TypeScript and JavaScript applications through static analysis.

Here I’ll explain why it’s so important to use ESLint in your application and I’ll describe the plugins I always add to every new NodeJs application to massively improve code quality and consistency.

If you install an npm package using yarn and you get this error it means that the package author is using windows line endings and Node.js on mac can’t run the script as expected.

env: node\r: No such file or directory

To fix it you need to change the line endings. But you need to ensure this happens after each install of packages!

If you try to use JSON.stringify() on a NodeJS object you will get an error “Converting circular structure to JSON”. This is because NodeJS objects have circular references.

The way to stringify NodeJS objects is to use util.inspect().

I got caught out with Microsoft recently setting the default version of Node.js from 12 to 14 on Azure pipelines linux build agent images (ubuntu-latest). Here are some tips for ensuring Node.js versions are set correctly in some of the popular Azure PaaS offerings.

I’ve been writing lots of Node.js apps on Azure recently. Azure provides an instrumentation product called Application Insights. The App Insights client hooks in to Node.js requests and other popular parts of the Node.js ecosystem like postgres with almost no configuration.

However If you want to use the performance measurement api you have to actually call the app insights Node.js client api method. I figured since this was measuring some wrapped code anyway it would be a great candidate for an es6 decorator.

I’ve been working with jest every day for the past month or so. I had to learn a few tricks as I went. I was mocking, using async, upgrading versions and working in vscode. Here are five things I learned.

Using semantic versioning allows you to completely automate updating versions in package.json and remove any arguments in your team about versioning. Here is how I use it in my Node.js apps.

If you are deploying a Node.js app to Azure App Services you can deploy the node_modules folder as part of the deploy, or you can reinstall the runtime Node.js modules on the host each time. There are some advantages and disadvantages to taking either option.

I recently had to add open api extensions for an AWS gateway to the output of Nest’s swagger/openAPI tool. This is how I did it and what I learned.

I was trying to deploying a Node.js app to azure app service recently but it kept timing out trying to download all the required modules.

I was able to fix this by specifying an explicit network timeout for the npm install in my azure-pipelines.yaml file

Here is some of the jest configuration I have for a Node.js application in typescript that builds on a CI system.

If you run yarn update on a package, yarn will update the package and your yarn.lock file. This is totally fine. As long as you check in your lock file, your developers and team will all have the correct versions of libraries when they run yarn install.

However it will not update the package.json with the new semver for the package. I kind of found this annoying, if only for aesthetic reasons I wanted to quickly see which minimum versions of packages I was using in package.json.

If you’re publishing a Node.js app on Azure pipelines you will want to publish the output of your tests. The publish tests task on Azure has limited format support so you have to convert the test results to XML for processing.

I’ve found this happens sometimes if I manually change the package config.

It’s a simple fix. You have to clean the cache.

I’m exploring the Azure Devops API at the moment and I find logging out the API responses is far better than trying to understand the documentation.

It seems super obvious now but it took me some messing around to figure out that you need to supply the object as meta data to the winston logger!

Cors protection is a recommended security configuration for any api. It protects your customers from unexpected attacks by blocking websites you haven’t approved.

If you have a devOps team they will handle this for you. But if you are a single maker with an application on Heroku and front end on Netlify you need to implement this yourself.