The Modern Programmer

Learn how to apply test coverage to your Typescripts projects.

Some naming conventions promote the use of the underscore character (" _ ") for those variables that must be declared but are not being used. One common case is that in which a function signature contains some variables that will not be used, as for instance the Express error handlers: app.use(function(err, req, res, next) { console.error(err.stack); res.status(500).send('Something broke!'); }); In the above example only the arguments err and res are being used, though all four must be defined in the handler signature. Thus, following the naming convention of using underscores for those unused variables, we could recode it as: app.use(function(err, _, res, __) { console.error(err.stack); res.status(500).send('Something broke!'); }); Though it makes the function more readable, it comes with a problem if using ESlint: it will blame by declaring unused variables. error '_' is defined but never used error '__' is define...

Google Cloud Tasks offer a good solution for controlling workflows in our backend infastructure, increasing load peaks resilency while keeping costs controlled. Such a powerful solution requires a careful configuration to properly work, specially when dealing with task retrying policy. This feature is basically controlled by a set of properties described in the Google Cloud documentation and quickly described here: minBackoff : Elapsed time in seconds, from the initial task execution, that defines the lower limit of the incremental retry time window. The first retry will occur minBackoff seconds after the initial task execution. maxBackoff : Elapsed time in seconds, from the initial task execution, that defines the higher limit of the incremental retry time window. After reaching maxBackoff the retry time will not increment, and retries will occur every maxBackoff seconds. maxDoublings : Number of times that minBackoff will be doubled (multiplied by two) in order to ...

Linting and formatting tools are common in the Javascript/Typescript (JS/TS) scene, and their benefits are out of discussion: linters allows applying a set of coding style rules, whereas formatters apply a set of not coding but format style rules. Used in a development team scenario, its usage allows unifying the codebase by applying a common set of coding and formatting rules, no matter who the coder was. However, if not properly configured, these tools can collide in their functions, being the most common case the linter formatting code, a task that might be performed by the formatter. This article exposes the way of proceeding in order to allow both tools living in armony. Install and configure a linter The most common linter in the JS/TS scene is ESLint since TSLint , in the moment of writing this article, has been deprecated in favour of the first one. To install ESLint run these commands: $ npm install eslint --save-dev $ npx eslint --init Once installed you c...

In Node, process.env property gives you access to the user environmental variables. Opposite to what you could think, these variables are always treated as strings , no matter the nature of your environment or the way you defined them. Misunderstanding of that said above can give you unpredictible behaviours, as that shown in the next code snippet regarding the usage of a presumably boolean env variable: process.env.FALSY = false; let evaluation = process.env.FALSY ? "This is imposible" : "This is the expected result"; // Since process.env.FALSY is returned as string, // and the bool value of a non empty string is true // it is evaluated not as falsy but as truthy The problem is not just related to boolean values, but also to numeric values, as shown the next code snippet: process.env.ONE = 1; let mustBeSix = process.env.ONE + 5; // Though you could expect mustBeSix being 6 // its result is the string concatenation // of '1' and '5' ie, ...

gcloud command line tool allow us managing a list of Google Cloud projects, one of which is considered as the default project, so all the operations we perform via gcloud are performed on it. Available projects To check what projects are available via gcloud , run the command: $ gcloud projects list This command drops an output similar to this example: PROJECT_ID NAME PROJECT_NUMBER fooOrg-pr01 Project Bar 239785793387 fooOrg-pr02 Project Zaz 348328582382 ... You can check the available options in the GCloud SDK reference . Current default project As you can see, that output doesn't set what is the default project. To get it run this command: $ gcloud config get-value project The command output will show the ID of the default project. Following the above example, the output of the command could be fooOrg-pr01 to state that the default project is our Project Bar. Changing the current default project To change the default project, run this comman...

How frustrating can be managing a big Typescript project in which all the module paths are relative to the importing file, as the next example. Every time we move a file, and therefore its relative path changes regarding its imported modules, we must sacrifice time and patience fixing a train of dots and slashes that too many times are fixed by trial and error. import {Request} from "express"; import {foo} from "../../../../types"; import {bar, baz} from "../../../../../myModules/bax"; Hopefully Typescript's tsconfig.json file allows specifying path aliases by setting the paths option. This option, together with the use of the npm package module-alias allows converting the previous mess into a piece of fine art: import {Request} from "express"; import {foo} from "@types"; import {bar, baz} from "@myModules/bax"; As said the process implies not just configuring tsconfig.json but also using the package...