A friend of mine, Terry, asked a question on Twitter.

A long time ago, I added this button to open the current folder in vscode.

I obvs want it to open cursor now, but can't figure out how I put it up there!

Anyone know?

— https://x.com/saltcod/status/1890727453124968831

Well, I did not know how to do it, but because I always like to learn random things and, most of all, help people, I decided to figure it out. Here's how to do it in a few simple steps.

1. Open the Automator app and create a new Application.
2. Add two steps: Run AppleScript and Run Shell Script.
3. Fill the AppleScript step with the script below. It will grab the currently active Finder window and extract its current directory.

on run {input, parameters}
	tell application "Finder"
		set currentFolder to (target of front window) as alias
		return POSIX path of currentFolder
	end tell
end run

4. Fill the Shell Script step with /usr/local/bin/zed "$1" or any other editor of your choice.
5. Press Cmd + S to save the automation. It should now be accessible under Applications on your system.
6. Go to your Applications, right-click the newly saved automation, and select Get Info.
7. Drag the application you used in your script and drop it on top of the small icon in the top left corner of the info window. This will give you a nicely styled icon.
8. Open a new Finder window (you need two separate windows for this step), right-click on the toolbar, and select Customize Toolbar....
9. Focus on your original Finder window with Applications, then drag and drop your automation next to the rest of your toolbar icons.
10. You're done! Now you can click your new shortcut in any Finder window, and it will open your editor with a workspace set to that very directory.

There are times when you don't have access to the internet. Be it during travel, on a plane, on a train, or during a layover. However, those are perfect opportunities to follow up on some of your favorite channels and clear up your long-overdue "Watch Later" playlist.

Using "Watch Later" is the most convenient way, as YouTube has a shortcut for it everywhere. In its web app as a small "clock" button, in the mobile app as a separate action, or in the TV app as an additional option in the overlay.

However, it's not possible to make this playlist publicly accessible. Because of that, any tool that could be used to use it as the data source for video fetching will require generating an authentication token in order to work.

Moving all videos from the "Watch Later" playlist to a regular, public one and then using it directly is one of the possible solutions, but it's cumbersome, and you have to remember to clean it up after each use.

Fortunately, it's easy enough to extract all the necessary urls using a small devtools snippet, and then plug them in directly into the prepared shell script.

As a prerequisit, you must have yt-dlp installed in your environment.

Once you open your "Watch Later" page, open the DevTools console and extract all the urls using the snippet below. It will find all the videos present on the current page, and for each of them get the href attribute, which points directly to the video itself.

We will also quote all the values and join them with a newline, so it's easier to quickly copy the result directly, without any manual modifications.

const videoElements = Array.from(
  document
    .querySelector("ytd-playlist-video-list-renderer")
    .querySelectorAll("ytd-playlist-video-renderer")
);

const links = videoElements
  .map((el) => `"${el.querySelector("a").href}"`)
  .join("\n");

console.log(links);

Not that we have all the data, we create a download.sh file in the desired directory and fill it with values in an appropriate place.

videos=(
    # newline separated list of links
    "https://www.youtube.com/watch?v=vxKBHX9Datw&list=WL&index=1"
    "https://www.youtube.com/watch?v=Q-WHRJPlL5g&list=WL&index=2"
    "https://www.youtube.com/watch?v=dQw4w9WgXcQ&list=WL&index=3"
)

for video in ${videos[@]}
do
  yt-dlp \
    --format 'bestvideo[ext=mp4][height<=720]+bestaudio[ext=m4a]/best[ext=mp4][height<=720]/best' \
    --no-playlist \
    --sponsorblock-remove default \
    $video
done

The script will iterate through all the videos, one by one, and feed them to the yt-dlp.

To quickly summarize what the flags mean.

• --format - file format parameters.
• bestvideo[ext=mp4][height<=720]+bestaudio[ext=m4a] - download the highest quality of mp4 format, with m4a audio format, but not larger than 720p
• best[ext=mp4][height<=720] - if not possible, download the highest quality of mp4 format, but not larger than 720p
• best - if not possible, fallback to whatever the best quality is available
• --no-playlist - do not attempt to fetch the next video in the playlist, as we provide the data ourselves, and the playlist is not public anyway (it looks at list query parameter, which is present by default in our extracted URLs, thus we'd get some noise)
• --sponsorblock-remove default - use ajayyy/SponsorBlock API to automatically remove some parts of the videos, that are sponsored, fillers, interactions reminders etc. By default it will remove all possible chapters

Once everything is set, we can either give the saved script executable permission with chmod +x download.sh and run it as ./download.sh. Or we can run it directly using sh ./download.sh.

That's it. Now everything should be available locally, and you can happily spend your downtime binging that sweet, sweet YouTube content.

According to Stack Overflow’s Developer Survey 2019, Go is the third most wanted language to learn, as well as the third-best paid technology in the field. It is not a surprise, as it is one of the languages used for writing critical parts of a lot of large systems. The language design and syntax are simple, but developing in Go is far from easy.

Some of the features Go provides:

• recovering from panic
• reporting errors
• recording breadcrumbs
• logging messages
• extracting stack traces from errors and panics
• errors filtering
• integration with various HTTP libraries
• async/sync transports
• serverless support
• extracting request/os/device data
• thread-safe data separation

We decided to spend some time on writing a new, unified SDK, that supports all recent versions of the language, utilizes its features, and gives developers the most helpful hints possible for where and why the error might happen.

Here’s what a Go exception looks like in Sentry.

Getting Started

sentry-go provides a Sentry client implementation, which is in-line with our Unified API guidelines and is intended to replace the old raven-go package. The SDK supports Go Modules by design; therefore, when installed, it picks up the latest version of the SDK and stores it inside the go.mod file. Non-major changes should never break your builds.

$ go get github.com/getsentry/sentry-go

The only thing you need to call to initialize the SDK is sentry.Init with a proper DSN obtained from your Sentry account.

sentry.Init(sentry.ClientOptions{
  Dsn: "YOUR_PUBLIC_DSN",
})

Once configured, you can start using any publicly available API, and it’ll track your data and report captured errors.

Now, let’s go through some real-world use-cases, as this sounds way more interesting.

Capturing Panics

Sentry provides two ways of recovering from panics: RecoverWithContext(), which can pass Context around, and Recover(), which does not pass Context around. Unless you are moving data around or using some cancel/timeout functionalities, Recover() is the way to go.

Below, we call a function that we know breaks by fetching a number from a slice that is definitely not there. How can we make sure that exception reports to Sentry? With Recover(), that’s how.

func bar() int {
  var luckyNumber []int
  return luckyNumber[42]
}

func foo() int {
  return bar()
}

func main() {
  // Initialize Sentry here

  defer sentry.Flush(time.Second * 5)
  defer sentry.Recover()

  foo()
}

By default, sentry-go uses asynchronous transport, which requires an explicit signal for event delivery finish using the sentry.Flush method. Otherwise, the program doesn’t wait for the async HTTP calls to return a response and exits the process immediately when reaching the end of the main function. sentry.Flush isn’t required inside a running goroutine or if you would use HTTPSyncTransport, which you can read about in our docs.

Capturing Errors

Reporting errors is even easier, because in Go, “error is just a value.”

var ErrMissingLuckyNumber = errors.New("Missing lucky number, sorry")
var luckyNumbers = map[string]int{
  "pickle": 42,
}

func getLuckyNumber(key string) (int, error) {
  if val, ok := luckyNumbers[key]; ok {
    return val, nil
  } else {
    return 0, ErrMissingLuckyNumber
  }
}

func main() {
  // Initialize Sentry here

  number, err := getLuckyNumber("pickle")

  if err != nil {
    sentry.CaptureException(err)
    sentry.Flush(time.Second * 5)
  } else {
    fmt.Println("Your lucky number is:", number)
  }
}

The same goes for simple messages.

// same getLuckyNumber implementation

func main() {
  // Initialize Sentry here

  if _, err := getLuckyNumber("pickle"); err != nil {
    sentry.CaptureMessage("Lucky number wasn't there, but let just log it as a message and proceed")
  }

  // the rest of your  program
}

Breadcrumbs

Breadcrumbs are a small message-hints that help track what went wrong during program execution, including some HTTP call, a DB query, data parsing, you name it.

Let’s simulate the scenario:

func performHTTPRequest(url string) string {
  sentry.AddBreadcrumb(&sentry.Breadcrumb{
    Message:  fmt.Sprintf("GET | %s", url),
    Category: "http",
  })

  // performing HTTP request
  return "I'm Pickle Rick!"
}

func performDBQuery(query string) string {
  sentry.AddBreadcrumb(&sentry.Breadcrumb{
    Message:  query,
    Category: "db",
  })

  // performing DB query
  return "https://example/com"
}

func processData(data string) error {
  return errors.New("something broke, sorry")
}

func main() {
  // Initialize Sentry here

  url := performDBQuery("Robert;); DROP TABLE Students;--")

  if data := performHTTPRequest(url); data != "" {
    sentry.AddBreadcrumb(&sentry.Breadcrumb{
      Message: data,
    })

    if err := processData(data); err != nil {
      sentry.CaptureException(err)
    }
  }
}

With this setup, your error has three beautiful breadcrumbs that look exactly like the on the screenshot in the very top of this blog post.

Contextual Data

Now and then, it’s useful to correlate some additional data with a captured panic or error. To do this, we also provide two methods: one that stores the data in the global Scope object and attaches it to every following event, and one that does this only for events captured in its callback function.

func main() {
  // This data will be attached to every event sent to Sentry
  sentry.ConfigureScope(func(scope *sentry.Scope) {
    scope.SetTag("isthis", "reallife")
    scope.SetExtra("oristhis", "justfantasy")
    scope.SetUser(sentry.User{
      ID: "1337",
    })
  })

  // For example this one
  sentry.CaptureMessage("hey there!")

  // However, this data will be only attached to the events that are captured inside it's callback
  // it'll contain global data configure above and its own "internal" one
  sentry.WithScope(func(scope *sentry.Scope) {
    scope.SetExtra("caught", "inalandslide")
    sentry.CaptureMessage("no escape from reality!")
  })

  // And this one
  sentry.CaptureMessage("hey there too!")
}

Goroutines

Capturing panics and errors, breadcrumbs, and contextual data are all well and good, but what about goroutines? No worries — we’ve got you covered.

The only thing you have to remember is that, in threaded environments, you have to take care of the data that’s living inside it, be it Scope instance or the Client you configure with sentry.Init. Thankfully, Hub keeps track of corresponding Scope and Client, allowing them to communicate with each other.

One of the methods that Hub uses is Clone, which (as you can guess) clones the top-most scope on the stack and reassigns the pre-configured client. Clone enables calls all major public APIs, but in a completely separated manner, where you don’t have to worry about overriding your scope data or race-conditions.

Here’s how:

func main() {
  // Initialize Sentry here

  go func() {
    localHub := sentry.CurrentHub().Clone()
    localHub.ConfigureScope(func(scope *sentry.Scope) {
      scope.SetTag("secretTag", "go#1")
    })
    localHub.CaptureMessage("Hello from Goroutine! #1")
  }()

  go func() {
    localHub := sentry.CurrentHub().Clone()
    localHub.ConfigureScope(func(scope *sentry.Scope) {
      scope.SetTag("secretTag", "go#2")
    })
    localHub.CaptureMessage("Hello from Goroutine! #2")
  }()
}

Hub and Clone make sure that the data belongs where it needs to and that captured events are enhanced in a correct way.

HTTP Packages

Our Go SDK provides integration with a variety of HTTP libraries: net/HTTP, Echo, FastHTTP, Iris, Gin, Martini, Negroni, and the list is still growing. Every integration automatically captures panics for your request handlers and exposes Request object for your disposal.

Let’s see how one may use it with one of the most popular packages, gin:

package main

import (
  "fmt"
  "net/http"

  "github.com/getsentry/sentry-go"
  sentrygin "github.com/getsentry/sentry-go/gin"
  "github.com/gin-gonic/gin"
)

func main() {
  sentry.Init(sentry.ClientOptions{
    Dsn: "YOUR_PUBLIC_DSN",
    AttachStacktrace: true,
  })

  app := gin.Default()

  // Gin has its own Panic handle, which sends 500 to the user
  // therefore after catching and reporting it to Sentry, we hand it over further
  app.Use(sentrygin.New(sentrygin.Options{
    Repanic: true,
  }))

  // Add some contextual data, that can be extracted from the request
  app.Use(func(ctx *gin.Context) {
    if hub := sentrygin.GetHubFromContext(ctx); hub != nil {
      hub.Scope().SetTag("someRandomTag", "maybeYouNeedIt")
    }
    ctx.Next()
  })

  app.GET("/", func(ctx *gin.Context) {
    // Use a Hub that is stored on the request's context (added by Sentry's integration)
    // And capture a message that will inform us about some unusual behavior,
    // despite request not panicking
    if hub := sentrygin.GetHubFromContext(ctx); hub != nil {
      hub.WithScope(func(scope *sentry.Scope) {
        scope.SetExtra("unwantedQuery", "someQueryDataMaybe")
        hub.CaptureMessage("User provided unwanted query string, but we recovered just fine")
      })
    }

    ctx.Status(http.StatusOK)
  })

  app.GET("/foo", func(ctx *gin.Context) {
    // sentrygin handler will catch it just fine, and because we attached "someRandomTag"
    // in the middleware before, it will be sent through as well
    panic("y tho")
  })

  _ = app.Run(":3000")
}

Note the AttachStacktrace client option that ensures, despite panic throwing just a string our way, we can extract the stack trace and add more context to the Sentry event report page.

What’s next?

Right now sentry-go is in it’s “pre-v1” stage. The SDK has a stable API that we test in the wild, but we look for ways to make it better (including listening to feedback). We already have some ideas that you can track in our GitHub issues page.

If you’d like to request a feature, help with implementing a feature, or have a better way of solving problems, feel free to let us know, and we’ll make sure that your voice is heard!

As you probably know, source maps allow you to view source code context obtained from stack traces in their original, untransformed form. This view is particularly useful when attempting to debug minified code (like UglifyJS) or transpiled code (like TypeScript or ES6). We’ve made the analogy before, but source maps act as the decoder ring to your secret (minified or transpiled) code.

As of recently, we support source maps for Node.js projects. Here’s what you need to know to generate and make those source maps available for Sentry.

Generating a source map

Most modern JavaScript transpilers support source maps. Below are instructions for two common tools: Webpack and Rollup.

Webpack

Webpack is a powerful build tool that resolves and bundles your JavaScript modules into larger chunks or a single file. It also supports many different “loaders” which can convert different flavors, like TypeScript, into plain JavaScript.

Webpack can be configured to output source maps by editing webpack.config.js.

const path = require("path");
module.exports = {
  entry: "./src/app.js",
  output: {
    path: path.resolve(__dirname, "dist"),
    filename: "bundle.js",
  },
  target: "node",
  devtool: "source-map",
};

Rollup

Rollup, another powerful bundler, is specifically focused on compiling small pieces of code into a larger structure, like a library. As an added benefit, Rollup is great at tree shaking, right out of the box.

Rollup can be configured to output source maps by editing rollup.config.js.

export default {
  entry: "./src/app.js",
  output: {
    file: "bundle.js",
    format: "cjs",
    sourceMap: true,
  },
};

Making source maps available to Sentry

Once the source maps for Node.js projects are generated, you can upload them directly to Sentry.

Uploading source maps to Sentry

Sentry provides an abstraction called Releases that is used to improve our error reporting abilities by correlating first seen events with the release that might have introduce the problem. Releases are necessary for source maps, and the Release API allows storage of source maps within Sentry.

Attaching source artifacts can be done with the help of the sentry-webpack-plugin, which internally uses our Sentry CLI, and these five steps:

1. Create a new authentication token under [Account] > API.
2. Select project:write under Scopes.
3. Install @sentry/webpack-plugin using npm.
4. Create .sentryclirc file with necessary config (see Sentry Webpack Plugin docs).
5. Update your webpack.config.json.

For more information on how to configure the plugin, check out the Sentry Webpack Plugin documentation.

const SentryPlugin = require("@sentry/webpack-plugin");
module.exports = {
  // ... other config above ...
  plugins: [
    new SentryPlugin({
      release: process.env.RELEASE,
      include: "./dist",
    }),
  ],
};

You’ll also need to configure the client to send the release:

Sentry.init({
  dsn: "https://e6c75451eb1344d9865ac11985f46946@sentry.io/1274678",
  release: process.env.RELEASE,
});

If you use process.env.RELEASE in your application’s code, you’ll have to provide that environment variable every time you run the app. Using Webpack, it’s much more suitable to use DefinePlugin and “embed” it during build time.

In that case, the code for webpack.config.js is:

const webpack = require("webpack");
// later in the config object, alongside sentry-webpack-plugin

plugins: [
  new webpack.DefinePlugin({
    "process.env.RELEASE": process.env.RELEASE,
  }),
];

You don’t have to use RELEASE environment variables, but release from your upload needs to match release from your init call.

For more information, check out the Releases API documentation.

Updating Sentry SDK configuration to support source maps

For Sentry to understand how to resolve errors, the data we send needs to be modified. You can update the Sentry SDK with the help of our RewriteFrames integration, which modifies that data for you.

Sentry.init({
  dsn: "https://e6c75451eb1344d9865ac11985f46946@sentry.io/1274678",
  integrations: [new Sentry.Integrations.RewriteFrames()],
});

This config assumes that you’ll bundle your application into a single file, which will be served and then uploaded to Sentry from the root of the project’s directory.

If you’re not doing this, because perhaps you’re using TypeScript and uploading your compiled files to the server separately, then we need to use a different approach. This different approach is outside the scope of the current post, but you’ll find some helpful hints and a details example over in our TypeScript documentation.

That’s it! Use it. Break things. Repair them. Break them some more. Repair them again. Break them one more time. Repair — you get the idea.

Post feedback in our forum or issue tracker, or shout out to our support engineers for help. And, of course, don’t forget to check out the source maps for Node.js documentation.

Internet Explorer and Edge throw errors in the end user’s language. If your end user speaks Polish, they throw a Polish language error. If your end user speaks French, they throw a French language error. If your end user speaks German they throw a Spanish language error, but only if that end user accidentally set their Windows language to Spanish and they aren’t sure how to fix it; otherwise the error is in German.

Now, if both you and your end user are Brazilian, seeing the error in Portuguese is not unhelpful.

An error in Polish, not Portuguese, but you get the point

The problem is that:

• No other browser does this. Chrome, Firefox, and Safari all throw errors in English.
• You’re very likely to have users who speak a wide variety of languages, which means you’re almost certainly going to end up with plenty of individual errors that each appear to be multiple different errors.

So if you had the same IE issue in 20 different countries, you’d end up with 20 different error messages. Though Sentry would still use the stack trace to group all these errors into a single Issue, the variety of messages could make it more difficult to measure an issue’s impact and severity, and then to appropriately resolve it once you’ve managed to do so. We’ve experienced this problem ourselves, puzzling over errors thrown in languages we don’t speak.

Which is exactly why Sentry now automatically translates Edge and IE errors to English.

How do we do that?

We have a large, indexed dictionary of almost every error across all IE supported languages (taken from this open-sourced dataset). Once the error is extracted from the client, we look over each frame of the stack trace to ensure it’s actually an error and not a custom message created by you, since a custom message wouldn’t be easily translatable.

We have the message. We have our dictionary. Now we can check to see if there’s a match somewhere. Let’s say we have an IE error in Spanish and it’s indexed in the dictionary as IE error number 962. We can then grab the number 962 message in English and create a regex that parses out the placeholders, like “There’s been an error [something here] with a value of [something else here] and yada yada yada.”

A translated error

And that’s pretty much that. Now most errors thrown in Edge or IE across ten languages will appear to you as one error in one language, making the problem easier to tackle.

Have questions? Don’t hesitate to reach out to our support engineers. They’re here to help. And also to code. But mostly to help.

npm is not only the package manager for JavaScript, it's also used to set up tooling around your codebase. Linters, transpilers, testing, and servers. Everything can be configured and run using the very same thing. Basic usage is really simple, too.

You specify your scripts within the scripts attribute of the main object in package.json and then run it using npm run <name>.

For example:

{
  ...
  "scripts": {
    "build": "webpack --progress",
    "test": "karma start",
    "server": "webpack-dev-server"
  }
  ...
}

There are, however, some details that may be useful while performing your setup.

Running Scripts with Additional Arguments

Let's say that you want to run Karma, which by default is watching all of your files for changes, without this feature.

To do this, they provide a --single-run flag that can be used with their script.

The simplest way to achieve this would be to add a new entry in our scripts.

For example:

"test:single-run": "karma start --single-run"

If we'd like to modify our default test parameters, however, we'd have to do this in both places, test and test:single-run.

Or we can go around this issue by using our flag directly from the command line.

To achieve this, we use -- at the end of our command, which tells npm that anything after this should be appended directly to the command itself.

$ npm run test -- --single-run

Running Multiple Commands in Series or in Parallel

If you have one script that runs multiple commands, let's say CSS linter, JS linter and HTML linter, it'd be nice to run them all at once to speed things up.

If you have commands that are dependent on each other, however, like if you run transpiler before running the tests, you'll want to change the execution flow to be one after another, not all at once.

Because npm scripts are spawning a shell process under the hood, we can use its syntax to achieve what we need. Specifically ; (and &&, more on this next) for running in series and & for running in parallel.

An example using this syntax could look something like this:

Parallel:

"lint": "eslint & csslint & htmllint"

Series:

"build": "babel; jest"

(I know, Jest test runner has a built-in functionality to precompile your code. It's only an example ;))

It will work just fine, but there's one rather huge issue with this approach. & syntax creates a subprocess, which results in the original npm process not being able to tell whether it already finishes or not. This can be problematic, especially with long running scripts.

To make things more coherent, we can use a package called npm-run-all. It provides additional commands, more specifically run-s for series and run-p for parallel, and it will handle all of the subprocesses correctly.

Parallel:

"lint": "run-p eslint csslint htmllint"

Series:

"build": "run-s babel jest"

Bailing out When a Command Fails

In our previous example, we run transpiler before we run our tests.

But what's the point of running the tests if transpilation failed in the first place?

; syntax waits until the former command finishes and then runs the next one, no matter what the exit code.

What we'd like to do instead is to stop the execution if any command in series failed.

To change this, we simply use && instead of ;:

"build": "babel && jest"

Now, if babel exits with a code other than 0, which means a successful command run, jest will never run.

We can, of course, chain this syntax as many times as we want:

"build": "eslint && babel && jest && deploy"

Using Life-Cycle Hooks

Every script in npm runs three separate scripts under the hood. A pre script, a script itself and a post script. Those two additional scripts are run, as their names imply, before and after the main script.

They are useful for setting up and cleaning up, for example, during deployment.

Both of those scripts can be written using pre<script-name> and post<script-name> in the same scripts object as before.

Let's say that we want to build our project, it'll be a very simple example just to show the concept.

What we'll do is this:

• create a new one dist directory and remove everything from it if there was already one
• create tmp directory
• build the project to tmp directory
• minify our bundle to dist directory
• remove the tmp directory

"prebuild": "mkdir dist tmp; rm -rf dist/*",
"build": "browserify main.js -o tmp/bundle.js && uglifyjs -o dist/bundle.min.js -- tmp/bundle.js",
"postbuild": "rm -rf tmp"

Note that you should use the rimraf package for cross-platform compatibility, as it won't work on Windows.

Now, whenever you run npm run build, it will trigger all the commands, making sure they were called in a correct order.

Running Group of Commands

The naming convention in npm uses a colon to group a whole set of specific tasks. In one of the code examples above, we run all lint tasks in parallel using & syntax.

What I often like to do is split those tasks into smaller chunks and run them as groups using the npm run command within the script itself.

Our previous example looked like this:

"lint": "eslint & csslint & htmllint"

What we can do is separate every single one of them (in case we need to add some flags to configure them, for example) and group them together.

"lint: "npm run lint:js & npm run lint:css & npm run lint:html",
"lint:js": "eslint --some-flag",
"lint:css": "csslint --that-will-change",
"lint:html": "htmllint --how-things-work"

After this change, it will work exactly the same way, but now we can run either all of them at once, or each one separately whenever we need.

To make it even cleaner, we could use an npm-run-all here again and change our main lint command to npm-run-all lint:*, which would then match all scripts starting with the lint: group.

npm Completion

One of the things I learned recently is that npm itself provides us with a baked-in way to add commands completion in the terminal. And what's even better is that it will also include all of your custom scripts!

Depending on your environment (bash or zsh), you just pipe the result of your npm completion command directly to ~/.bashrc or ~/.zshrc. Remember to reload this file afterwards using source ~/.bashrc!

$ npm completion >> ~/.bashrc
$ npm completion >> ~/.zshrc

Writing Custom Checks for Your npm Scripts

Thanks to the && syntax and npm understanding regular exit codes as described above, we can write very simple node scripts that will do some initial checks for us.

For example, making sure that the user specified all of the required ENV variables or that the command name doesn't contain any typos when trying to run it.

What I used recently, is this nodel.js script verifying that I have NODE_ENV set up and that developers are using one of the predefined env-specific scripts.

My scripts look something like this:

"build": "node ./scripts/env-check.js && rimraf dist && webpack --bail --progress --profile --display-error-details",
"build:development": "NODE_ENV=development npm run build",
"build:staging": "NODE_ENV=staging npm run build",
"build:production": "NODE_ENV=production npm run build",

And env-check.js content:

const task = process.env.npm_lifecycle_event;
const packageJSON = require("../package.json");
const availableEnvironments = Object.keys(packageJSON.scripts)
  .filter((key) => key.startsWith(task))
  .map((key) => key.split(":")[1])
  .filter((key) => key);

if (!process.env.NODE_ENV) {
  console.error(
    `[ Error ] NODE_ENV is required. Use ${task}:${availableEnvironments.join(
      "/"
    )} scripts instead.`
  );
  process.exit(1);
}

if (!availableEnvironments.includes(env)) {
  console.error(
    `[ Error ] ${env} is not valid NODE_ENV. Use ${task}:${availableEnvironments.join(
      "/"
    )} scripts instead.`
  );
  process.exit(1);
}

process.exit(0);

Now, whenever a developer types npm run build directly, this prompt will show up:

$ [ Error ] NODE_ENV is required. Use build:development/staging/production scripts instead.

One drawback of the code above is that it won't understand pre script, which seems like a perfect place for this check:

"prebuild": "node ./scripts/env-check.js && rimraf dist",
"build": "webpack --bail --progress --profile --display-error-details",

To fix this, we'll have to update the task variable, as process.env.npm_lifecycle_event won't return a build name, but rather prebuild.

const task = process.env.npm_lifecycle_event.startsWith("pre")
  ? process.env.npm_lifecycle_event.slice(3)
  : process.env.npm_lifecycle_event;

Now, we can place node ./scripts/env-check.js in any pre script, and it will perform all of those initial checks for us.

I personally use it for build, server and deploy scripts, but it can certainly be effectively used in many more places.

One of the most mundane and frightening tasks for many developers is writing integration tests. It's a time-consuming, fragile, and often difficult and frustrating task to accomplish. What makes it even worse is that it quickly gets out of hand and breaks often, which leads to frustration and dropping the idea completely.

What's the worst thing about writing integration tests? DOM? Promises? Asynchronicity? Some strange framework API behavior? I'd say: all of them.

We've all been there. Element is not in the DOM but it should be. Request came back from the server too late (why weren't you mocking your responses in the first place, huh? ;)). Promise is still unresolved. My app's state changed but those changes haven't propagated to all components yet. I changed my route's hash or query parameter, and test runner didn't catch that.

I got a false positive. I got a false negative. I got a race condition. I got inconsistent results. It works locally but my headless CI breaks.

Aaaaagr@#$%^&...! Damn you, Selenium. I'm done with you! I'll just trust that I won't make any mistakes and I won't need integration tests. I'm sure I'll be fine.

...One month later, on your company's Slack channel...

Failed: awesomeJoe's build (#404; push in ImTooAwesomeForTests/ThisForSureWontBreakAnything (this_for_sure_wont_break_anything)

Refactored like 95% of the App, but I'm sure it's working and we'll be fine (b4d455 by awesomeJoe)

Failing tests: If you see this, you know that you messed up

The World Where Browser Is Not a Black Box

Protractor, Pioneer, Nightwatch.js, Intern and probably plenty of other testing frameworks out there in the wild use something which is called Selenium. Selenium is this magic black box that can understand your code and make browsers do what you ask them to do. Navigate to pages, click elements, get values, fill forms, control back/forward buttons, etc. But it being a black box can be problematic. Especially when testing asynchronous code.

What happens is the following: when your test runner issues a test, it asks Selenium to ask a browser and returns an answer to you. For example, if you want to know whether a given element is already rendered, you ask Selenium to ask a browser, which in the end checks the existence of an element, gives that answer to Selenium, which hands it back to you. In other words, it's a middleware between your test runner and a browser. A black box.

It's problematic, because we have no knowledge of the browser's lifecycle, or "event loop." We cannot wait for something to finish, know whether there are some unresolved promises or pending requests. If you ask Selenium for something, it'll blindly go to the browser and fetch your answer.

This is where Cypress shines. It's a complete test runner, which lives inside a browser, alongside your own application code. It knows everything about browser state, event loop, as well as your application's code.

This simplifies things a lot! It will politely wait for all the things to happen first, before issuing your test assertions. And even more, it will wait for the previous command to finish, before moving to another one, as everything is promise-based. You don't have to use timeouts or any code like this anymore (thankfully, as timeouts are one of the biggest, if not the biggest source of race conditions and nondeterministic results).

"But wait, there's more!" A thing that helped me even more is a perfectly-crafted debugging environment. Every test that you run in Cypress saves the browser's state after every step. XHR Request, click, element query, location change. And you can go back and forth between those states, read the errors, debug an issue as you'd normally do in devtools, see the before/after screenshots. It's so useful!

And yes, I know it's closed Beta right now, but their team is really awesome, and they give away an access to everyone on their gitter.io channel. You should definitely come and say hi!

And I highly recommend watching the following official demo from the Cypress team:

Cypress.io - Overview Demo from Brian Mann on Vimeo.

Code for Tests

"Alright, show me the magic now!" Well, there's no magic. The Cypress API is dead simple. But, ok, ok, here it is:

describe("Navigation", function () {
  beforeEach(function () {
    cy.server().stubUserSession();
  });

  // your tests go here
});

What's that stubUserSession, you ask? It's our custom command we can create to make our code more DRY. Let's see its content:

Cypress.addParentCommand("stubUserSession", function () {
  const log = Cypress.Log.command({
    name: "stubUserSession",
  });

  cy.route("POST", /session/, "fixture:session/valid", { log: false }).then(
    () => log.snapshot().end()
  );
});

What a beautiful code! You create a command, give it a name, and ask to intercept all requests made to urls matching /session/ RegExp. When it finds one, it will serve our fixtures/session/valid.json file and prevent the browser from making a real request. It will give us 100% repeatability.

Now, it's time for some actual tests.

it("should render all elements when user is logged in", function () {
  cy.visit("/dashboard")
    .get("[data-hook=navigation-header]")
    .should("exist")
    .get("[data-hook=navigation-footer]")
    .should("exist")
    .get("[data-hook=navigation-sidebar]")
    .should("exist");
});

I highly recommend using the [data-hook=*] pattern in all of your integration tests' code. It's a great way to separate concerns and specifically point out that it shouldn't be touched in your HTML code.

<h1 id="page-title" class="make-it-shine">Hello World!</h1>

You can query this element using #page-title or .make-it-shine selectors. But what happens when a designer comes to remove/change them? How can we know it's not referenced somewhere?

<h1 id="page-title" class="make-it-shine" data-hook="page-title">
  Hello World!
</h1>

And now, you can simply use [data-hook=page-title], and it won't break if someone changes id or a class.

Alright, back to the tests.

it("should display correct logo based on the current location", function () {
  cy.visit("/dashboard")
    .get("[data-hook=navigation-logo-dashboard]")
    .should("exist")
    .get("[data-hook=navigation-logo-search]")
    .should("not.exist")
    .visit("/search")
    .get("[data-hook=navigation-logo-dashboard]")
    .should("not.exist")
    .get("[data-hook=navigation-logo-search]")
    .should("exist")
    .go("back")
    .get("[data-hook=navigation-logo-dashboard]")
    .should("exist")
    .get("[data-hook=navigation-logo-search]")
    .should("not.exist")
    .go("forward")
    .get("[data-hook=navigation-logo-dashboard]")
    .should("not.exist")
    .get("[data-hook=navigation-logo-search]")
    .should("exist");
});

All those routes are client-side rendered, and the logo element reacts to an asynchronous change of the application's state (which is event-based in this scenario). We can see a usage of location controls as we use back/forward buttons and assertions negation using not.

Let's do something more complex. Let's manually log in a user, verify redirect, go to a search section and log them out, making sure that they have been redirected, but this time to the login form.

it("should allow user to login, navigate and logout from the app", function () {
  cy.server({ enable: false })
    .visit("/login")
    .server({ enable: true })
    .route({
      method: "POST",
      url: /session/,
      status: 200,
      response: "fixture:session/valid",
    })
    .get("[data-hook=login-form-username")
    .type("john.doe@example.com")
    .get("[data-hook=login-form-password]")
    .type("verysecurepassword")
    .get("[data-hook=login-form-submit]")
    .click()
    .url()
    .should("match", /dashboard/)
    .get("[data-hook=navigation-links-search]")
    .click()
    .url()
    .should("match", /search/)
    .route({
      method: "DELETE",
      url: /session/,
      status: 204,
      response: {},
    })
    .route({
      method: "POST",
      url: /session/,
      status: 401,
      response: "fixture:session/invalid",
    })
    .get("[data-hook=navigation-logout]")
    .click()
    .url()
    .should("match", /login/);
});

It's only that much code and it works like a charm. One note about those two route changes. The first one is stubbing our delete session request, which will be issued once we click the logout button. And the second one is overriding our previous valid session, changing it to invalid. Why? Because if you don't do this, and your application is correctly validating the user's authentication state, it would still think that you're authenticated and most likely (if you implemented it that way), will redirect you back to a dashboard.

You may also be wondering about .server({enable: false}) and .server({enable: true}). Remember how we used stubUserSession in our beforeEach block? It applies to all tests. And if we were to omit turning off requests interception here, our .visit('/login') call would redirect us instantly to a dashboard, as the application would think that we are already authenticated and there's no need to do this again. That's why we change the order. We disable our server stubs, go to the login page and only then attach the stub again. This way our initial /login call won't return an authenticated session. We could also do this by removing stubUserSession from beforeEach, and using it only when needed, or like this:

it('should allow user to login, navigate and logout from the app', function () {
  cy
    .route({
      method: 'POST',
      url: /session/,
      status: 401,
      response: 'fixture:session/invalid'
    })
    .visit('/login')
    .route({
      method: 'POST',
      url: /session/,
      status: 200,
      response: 'fixture:session/valid'
    })

    ...
})

The last test I'd like to show you is verifying that we can change the location's state (e.g. using HistoryAPI) directly, then through button clicks, and then using the back button, just for good measure. And making sure that other components, like search results can react to it.

it("should filter search results based on query parameters", function () {
  cy.stubSearchResults() // a stub that will return a 200 code response with 10 search results, 3 about places and 7 about people
    .get("[data-hook=search-form-query]")
    .type("Poland")
    .get("[data-hook=search-form-submit]")
    .click()
    .url()
    .should("not.match", /searchFilter=/)
    .get("[data-hook=search-results]")
    .children()
    .should("have.length", 10)
    .visit("/search?searchFilter=places")
    .get("[data-hook=search-results]")
    .children()
    .should("have.length", 3)
    .get("[data-hook=search-form-filter-people]")
    .click()
    .url()
    .should("match", /searchFilter=people/)
    .get("[data-hook=search-results]")
    .children()
    .should("have.length", 7)
    .go("back")
    .url()
    .should("match", /searchFilter=places/)
    .get("[data-hook=search-results]")
    .children()
    .should("have.length", 3);
});

Results of tests for one of the components in an app I'm working on right now:

I've shown you less than 10% of what Cypress can actually do. Give it a spin, it can be set up within minutes and doesn't require any code changes in your application. It cannot get easier than this.

Yes, You Should Write Integration Tests

Because, why not? They are the best way to tell if your application is working correctly. They allow you to iterate quickly, refactor large chunks of your application without fear of breaking it, and they are really easy (and fun!) to write. It's a great feeling to see your application being tested in real-time, seeing all the things being clicked, manipulated, forms filled and tests passing and changing color to green.

Don't be frightened, they won't bite you. They can only help you to be a productive and happy person. Your stress level will go down, your cortisol will drop, and you'll be able to get better sleep, build more muscles and lose fat more quickly, which will result in you being healthier. Because health comes first. It's basic logic. Write your integration tests. You'll be healthier and live longer. Don't thank me, just trust me. Been there, done that.

Clojure, as described on their official page:

"Clojure is a dynamic, general-purpose programming language, combining the approachability and interactive development of a scripting language with an efficient and robust infrastructure for multithreaded programming. Clojure is a compiled language, yet remains completely dynamic – every feature supported by Clojure is supported at runtime. Clojure provides easy access to the Java frameworks, with optional type hints and type inference, to ensure that calls to Java can avoid reflection.

Clojure is a dialect of Lisp, and shares with Lisp the code-as-data philosophy and a powerful macro system. Clojure is predominantly a functional programming language, and features a rich set of immutable, persistent data structures. When mutable state is needed, Clojure offers a software transactional memory system and reactive Agent system that ensure clean, correct, multithreaded designs."

Why Functional Programming

If you've never tried functional programming development, I assure you that this is one of the best time investments you can make. You will not only learn a new programming language, but also a completely new way of thinking. A completely different paradigm.

Functional programming is on the rise. Clojure, Scala, F#, Erlang, Elixir, Elm, Haskell, only to name a few. Those are all functional languages, used by the biggest companies in the world to drive their major systems.

It's good to understand how they work, but it's even better to be able to write something using them. Always remember one thing: "A programming language is just another tool." You should always pick a language based on your needs, not on how hyped it is or how much you love it. FP is the biggest paradigm next to OO and learning its basics will be worth it long term.

Why Clojure

"Made simple"

Rich Hickey made it very clear that Clojure is, and will always be, a simple language. Minimal syntax, very condensed and short API, no types. That simplicity, when comparing to other functional languages, makes it relatively easy to learn Clojure.

There's no better way to understand the reasoning behind the choices than to listen to the creator himself. In just an hour, you'll get it:

Clojure Made Simple - Rich Hickey

If you still need convincing, here is more of his reasoning:

Simplicity Matters — Rich Hickey

Hammock Driven Development — Rich Hickey

Even Robert C. Martin aka Uncle Bob likes it! In my eyes, that's an extra five points in favor of "why I should choose Clojure."

Java

I know, people tend to hate on Java because it's a huge monolith, yada, yada, yada, and it's Java. And for most of them, it should be put on the cons list rather than on the pros. But take a look at it from this perspective:

• plenty of people already know Java
• you can run it on almost anything
• there are well-established tooling and libraries
• it's battle tested

Other than for personal beliefs, I don't see why you wouldn't give it a try. Just like when you were introduced to new foods as a child, there's a huge chance that "you don't like it" without even having tried it. Yeees, I know everyone has done that at least once in their lifetime!

ClojureScript

ClojureScript is a compiler for Clojure that targets JavaScript.

To paraphrase Sauron: "One language to rule them all, One language to find them, One language to bring them all and in the darkness bind them."

What if you could kill two birds with one stone? Would that convince you even more?

"Developers hate him! See how he targeted all the biggest platforms using one simple trick!"

Java is huuuge, we all know that. But you know what's the second biggest platform? Web. Browsers. Internet of Things. You can target all of those platforms with one language.

ClojureScript is exactly the same thing as Clojure, but it's compiled and emits JavaScript code. It takes care of all the quirks and can be transpiled almost exactly 1-to-1. Almost. There's always something, and this time we have to keep in mind that there's Java interop for Clojure and browsers API interop for ClojureScript, but it's a minor part of the language. All the core things work in the very same way. You can find plenty of case studies where people have taken their huge Clojure applications and translated them to JavaScript within a day or two.

The best introduction to this concept is this talk: Clojure All the Way Down: Finally a Useful LISP — Ricardo J. Méndez

How

"Alright, but how should I approach my learning process?"

There are two ways: books and videos. Some people prefer the former and some the latter. I tried both and, to be honest, the latter one is my preferred method (although you might think it's the other way around by the photo I chose as an intro to this post). I enjoy the feeling of being "mentored" very much. I just like it more when someone is talking to me and demonstrating how things are done, rather than just reading about it.

Books

There are tons of books about Clojure. Clojure in Action, Clojure Programming, The Joy of Clojure, but I'd like to focus on two positions:

• Clojure for the Brave and True — Daniel Higginbotham It's not often the case, but this book is FREE and you can jump to reading it straight away. Of course, I highly encourage you to buy a printed copy! It's one of the best books you can find on the topic. It explores it in a very easy to digest manner and approaches it from the point of view of people completely new to the functional programming world.

• Living Clojure — Carin Meier Carin's writing is the shortest of all the mentioned books, and it's also the most condensed one. You'll find everything you need to start your journey with Clojure. It's also written somewhat as a tale about "Alice's Adventures in Wonderland." How cool is that?! It also contains what I found to be a great concept that could also help many of you: a "Weekly Living Clojure Training Plan!" It's split into seven weekly assignments, and step-by-step guide to learning Clojure.

Courses

PurelyFunctionalTV — Eric Normand

This is the best resource I've ever found when it comes to learning a new language from scratch. It holds your hand and guides you through all the basics, advanced topics and writing a whole complex application, explaining everything along the way.

The Clojure Language — Brian Will and Clojure Fundamentals — Alan Dipert

Those two series are front-to-back introductions to Clojure. They both go through all the core concepts of the language and contain everything you need to know to start working on your projects.

Lambda Island

This one isn't a course "per se," but rather a series of tutorials on Clojure and ClojureScript. Very useful when we are at a given point in our learning process and would like to dive deeper into a specific topic.

Additional resources

Although I'll openly admit that I haven't read them yet, these are books that were often recommended. I am told they provide more understanding about Functional Programming. I'll read them one day!

• The Little Schemer by Daniel P. Friedman and Matthias Felleisen
• Structure and Interpretation of Computer Programs by Harold Abelson, Gerald Jay Sussman and Julie Sussman
• Purely Functional Data Structures by Chris Okasaki
• An Introduction to Functional Programming Through Lambda Calculus by Greg Michaelson

If you love old architecture and castles, you'll fall for Bratislava. Easily one of the most beautiful places you can visit in Europe, this Slovakian capital is small enough that you can drive/walk quickly to most places, but big enough to fill your schedule for a few days. It's also very close to Vienna (Austria), making it a real two-for-one bargain! Both places are very cheap, offer plenty of attractions and great -- oooh great -- food! It may surprise some to find out that, when it comes to software development, the area is very quickly becoming one of the European tech hubs. Last month, Bratislava hosted two big conferences in one week:

• EuroClojure, the biggest Clojure-related conference, created by Cognicast (a company where Rich Hickey, creator of Clojure, and David Nolen, creator of ClojureScript, both work), and
• ReactiveConf, which gathers all the ideas around reactive programming, asynchrony, real-time, React.js or React Native.

The Extras

Both conferences were hosted in the Old Market Hall, called Stará tržnica. It's a huge, open-space building, and everything took place in the big room, which has a balcony surrounding it. It was a great idea to hold the event there, as you could always go grab a coffee, some pastries and still enjoy your talks, without missing a second. The sound was also very good, and you could hear everything from almost every place in the room. And the addition of a few screens only made it all that much easier.

The food (even though on the first day of EuroClojure I missed lunch :( because I went for a walk and they didn't have enough food) was just top-notch! I was even joking that they make my bulk-season very easy, as I could eat everything in there, and still wouldn't have enough. Slavic cuisine is just something that you have to try, and I promise, you'll fall in love with it.

Swag and promotional materials were very detailed and minimalistic. No unnecessary things, just a t-shirt, local honey wine and a snack. All useful things! I loved the schedule, which was printed as a page from an old paper, and the personalized stickers from ReactiveConf, where they used the speakers' talks to create wordplays: eg. "Clojure your eyes for David Nolen," "Rethink your DB with Michael Glukhovsky," "Look at the code from the different Angular with Igor Minar," "Spend 3 days in magic rEaLM with Richard Feldman." Unfortunately, the schedule wasn't useful during Day 1, as it changed quite a lot. I would have liked to have it printed on the small badge, or as an additional badge with only the schedule on it.

Oh, let's not forget about the after-parties! Although I'm a huge introvert and rarely talk to strangers (Ha! I forced myself just once during the last after-party, to talk to and thank David Nolen for all his talks, knowledge and work), I went to each one of them. And boy, oh boy, that Ice Bar after the first ReactiveConf's day was a blast! About -10 C (14 F), the room covered with ice, shot glasses made of ice that you could break after drinking your shot, and blue and red lights everywhere. Wow!

The Talks

My one-sentence summary for each of the conferences would be:

• EuroClojure – "Am I really that stupid?"
• ReactiveConf – "I've already seen it somewhere."

I don't know much Clojure (yet!), but I really want to learn it. This conference simply showed me just how much of a long haul that will be. But I'll get there… one day!

And don't get me wrong on ReactiveConf, it was a great experience, and I learned a lot of new things. But as a person who follows "Twitter Trends" every day, watches all conference recordings and reads quite a lot of articles, I simply felt that I already knew most of the elements presented in the talks. It felt like some things were just iterations on technologies that our industry saw years ago, and we are now coming full circle on.

EuroClojure

I enjoyed a lot of talks, but some of them just blew me away. My best of EuroClojure:

Keynote: Now What? – David Nolen

One of my favorite speakers ever. He's the creator of ClojureScript, and every single talk of his is great. He takes and moves ideas from one programming paradigm or from one language to another, which so far works great. Heard of immutability, single state atom, hot-reloading or pure functions for UI development? ClojureScript has it all. This time, he was talking about how he wants to take ClojureScript to a much larger audience, what pieces of language he will focus on, what are the fundamentals that we should never forget, and how to make it easier for newcomers to get into the language.

Clojure Is Not Afraid of the GPU – Dragan Djuric

Performing millions of mathematical operations using a hardware that's more suitable than CPU, our good old GPU. How the internal works, why is it so hard to do that now, and how it compares to CPU operations. He described a few libraries that he wrote and how they compare to the same functions written in Clojure, Java, C, Python or other libraries written in mentioned languages. He was able to get as low as seconds instead of hours, or microseconds instead of milliseconds which sounds almost impossible!

Making Machines that Make Music – Srihari Sriraman

Generating music as close to "human" as possible. Using machine learning predictions to determine how to do it was a great idea. He showed how to translate music (Indian music, I believe, which sounds very different than our western music) and its concepts to a "computer language" and how to generate random melodies that sound like they have been actually written by us, humans.

Keynote: Genetic Programming with clojure.spec – Carin Meier

Self-healing code and clojure.spec, just wow! The concept of a function that's able to modify itself, based on other "donor" functions is simply awesome. And using clojure.spec to do that makes it much simpler than you thought. The first part of the talk covered how we can distinguish developers using the so-called "Four Tribes of Programmers": Explorers, Alchemists, Wrestlers and Detectives. I really like that idea, it reminds me of Corgibytes' Makers and Menders. And what is clojure.spec exactly and how we can use it for genetic programming. You should definitely see that talk for yourself! But until it's released, here are the slides. Enjoy!

ReactiveConf

And, now, my best of ReactiveConf:

Testing the Way It Should Be – Brian Mann

Cypress.io, functional testing framework, written from scratch, without Phantom.js which was the main source of most of the problems with testing nowadays. It looks great, works great and is already in beta. You just have to ask for access. It provides you with time travel, dom snapshots, great error messages, a very simple and readable API and makes working with async code a cinch. Not only do they provide a library, but also an electron-based UI, which speeds up your workflow quite a lot! I will definitely use it with my next project as soon as I can.

Visualizing the Data Flow With Cycle.js – André Staltz

A lot of people say André Staltz is a very controversial persona, but I have to admit that he is frequently right and he's able to change how people think about some concepts. And that's huge! I also heard that he's a Rockstar, but I cannot confirm that, as he forgot his shades (see the very same talk's vid from FutureFest to see what I'm talking about ;)). How observables work presented using Legos, yes, the very same Legos you probably played with as a child. How they work, why it is easy to debug them and how to do this, why we lack good debugging tools and why debugger just shows you a detailed picture of your code, instead of a whole picture. Mental model of a software is something that we don't think enough about, and this is one of the issues that he is trying to solve. He presented Cycle.js Developer Tools that makes reasoning about your code much easier by visualizing a whole data flow for every single action or observable event.

No Xcode, Android Studio, Java, Swift, Objective C - How Far Can JavaScript Get You? – Brent Vatne

He talked about Exponent, which is a "framework" on top of React Native. It helps you with a lot of mundane tasks that require plenty of boilerplates and unify some things across Android/iOS development. But best of all, it doesn't make you use XCode or Android Studio! I had the "pleasure" of working with React Native last month on a new project, and the biggest pinpoint was indeed Android Studio. It's slow, CPU and memory heavy and it takes some time to actually get it running, even when following a simple step-by-step tutorial. I'll definitely give Exponent a try the next time I'm working with a mobile app.

That's it for now.

See you next year, folks!

In an era of omnipresent frameworks, libraries and tooling, it may be hard to decide what tool to use and when.

I know from experience, that the first thing you do, once you decide to write a module or CLI tool, is set up an environment. Some people love it, some hate it. But no matter on which side you are, you'll most likely end up spending way too much time doing it, polishing every aspect of the setup.

Sure, you could use webpack, eslint, jasmine or even TypeScript to get great compile error messages. The truth is though, most of the time, as developers, we can get by with tools that require almost no configuration. These "out-of-the-box" tools are usually perfectly acceptable, and will help us jump straight to solving the problem, while providing an almost instant feedback loop.

When talking about the minimal setup, things that come to mind are testing, linting, watching changes and making sure that you won't break anything before committing changes.

Here's a step-by-step to help you go from having nothing, to being productive in five minutes or less (depending on NPM's mood).

Init Node.js project and GIT repository

# Create a directory and cd into it (#protip – $_ holds argument of your last command)
$ mkdir awesome-module && cd $_

# Initialize Node.js project with default settings
$ npm init --yes

# Create initial folders and files
$ mkdir lib test
$ touch index.js lib/meaningOfLife.js test/index.test.js test/meaningOfLife.test.js

# Initialize GIT repository and create initial commit
$ git init
$ git add -A; git commit -am "Awesome Module, day one"

Install tools

Here, we'll use four simple modules, each having a single purpose. Ava for testing, Standard for linting, Chokidar-cli for file watching and Precommit-hook for automatically running npm scripts.

Why those tools? Because they don't require any configuration and take the cognitive load from your brain. One less thing to think and worry about.

$ npm i --save-dev ava standard chokidar-cli precommit-hook

Remember to create a .gitignore file and add node_modules to it! We don't want it in our repository.

Set up tools

Open package.json and add those scripts to your file.

"scripts": {
  "test": "ava",
  "lint": "standard",
  "dev": "chokidar '**/*.js' -c 'standard && ava'"
},
"pre-commit": ["test", "lint"],

Aaaand you are done! Once you run npm run dev you'll get all of your JS files linted by Standard.js and tests run by Ava. There's nothing more to it, and you can start working right away.

The same goes for creating GIT commits. You won't be able to do so, unless all of your tests are green and linter is happy.

Two things worth noting:

1. You don't have to install standard or ava globally, as they are run from within the node context.
2. Because we use && instead of ; here in the dev script, tests won't be triggered unless you pass linter rules. It makes the feedback loop even faster.

Working with the setup

Because the environment assumes you'll work in TDD style (and you probably should!), once you run your dev script, you can create tests and they will be added to the test suite, without any need for restarting a watcher or rebuilding anything.

Let's create the first test.

// test/meaningOfLife.test.js
const test = require("ava");
const meaningOfLife = require("../lib/meaningOfLife");

test("Real meaning of life", (t) => {
  t.is(meaningOfLife(), 42);
});

Once you save the file, you'll get instantly notified that one of your tests is failing. Let's fix it.

// lib/meaningOfLife.js
module.exports = () => 42;

And we are back to green! It's as simple as that. Let's create another module that'll multiply a numeric parameter, unit test this module and see whether it'll work nicely with our "meaning of life" (note that it's already an integration test, not unit!).

// lib/multiply.js
module.exports = (number) => {
  if (typeof number !== "number")
    throw new TypeError("Only numbers can be multiplied!");
  return number * 2;
};

// test/multiply.test.js
const test = require("ava");
const multiply = require("../lib/multiply");

test("Can multiply numbers", (t) => {
  t.is(multiply(10), 20);
});

test("Throws when you try to multiply non-number value", (t) => {
  t.throws(() => multiply("ohai!"), "Only numbers can be multiplied!");
});

Now, to test it all together:

// test/index.test.js
const test = require("ava");
const awesomeModule = require("../index");

test("Works nicely together", (t) => {
  t.is(awesomeModule(), 84);
});

// index.js
const meaningOfLife = require("./lib/meaningOfLife");
const multiply = require("./lib/multiply");

module.exports = () => multiply(meaningOfLife());

It works! In just a few minutes, we got everything up and running.

We, as developers, are often charmed by shiny new tools. We seem to forget that those things should make our work easier, faster and less error prone. The simplest solutions are more than enough, more often than we think. Instead of spending an enormous amount of time on the setup, we should spend it on writing the software itself. And following these steps will allow you to do just that.

Once your project starts to grow, you may find yourself in need of something more complex. In most cases, however, it just won't happen. And those tools will suit your needs quite well for a long, long time.