DEV Community: Vladimir Simonovski

Get hooked on Git hooks

Vladimir Simonovski — Sat, 11 Jan 2020 00:00:00 +0000

If you’re like me, you’re crazy over automating boring stuff. One of the things I got hooked on (pun intended) during the last year, and which helps in that automation process, is Git Hooks. If you haven’t heard of Git Hooks and want to see some cool ways of improving your daily git workflow stay tuned!

What are Git Hooks? 🎣

This page from Git documentation sums it up pretty well but in general Git Hooks are Gits answer on firing custom event when some Git related action occurs. We will focus on client-side pre-commit and commit-msg hooks today but following options are available:

Client-Side Hooks

pre-commit - runs before we even type the commit message.
prepare-commit-msg - runs before the commit message editor is opened up but after the default message is created.
commit-msg - good place to validate project state or the commit message before allowing commit to proceed further.
post-commit - runs after the entire commit process is completed, used mostly for notifications.
pre-rebase - runs before the rebase.
post-merge - runs after the successful merge.
pre-push - runs during the Git push.
pre-auto-gc - runs before Git triggers a garbage collector.

Server-Side Hooks

pre-receive- the first script that is run on the client-side push, if it exits non-zero,the push is not accepted.
update - pretty similar to the pre-receive excepts it runs once for every branch that the client-side wants to update. For example, if we’re pushing to five branches at the same time, pre-receive will run once, update will run five times.
post-receive - similar to the client-side post-commit just on the server-side.

Talk is cheap, show me the code

Since Git hooks don’t have the best out of the box experience, we’ll use the Husky library to make stuff easier:

yarn add husky --dev

You’re now able to include hook definition inside package.json like this:

// package.json
{
  // ...
  "husky": {
    "hooks": {
      "pre-commit": "<cool-script>",
      "commit-msg": "<even-cooler-script>"
    }
  }
  // ...
}

pre-commit

In most of cases we want to run the pre-commit hook only on staged files, lint-staged library helps us with that:

yarn add lint-staged --dev

After we’ve added the lint-staged we’re able to do something like this inside a package.json:

// package.json
{
  "husky": {
    "hooks": {
      "pre-commit": "lint-staged" }
  },
  "lint-staged": { "*.{js,md,css,scss,html}": ["<yet-another-cool-command-1>", "<yet-another-cool-command-2>"] }}

Now when we know the basics, it’s time to start adding scripts that will help our repository become better place ✨.

First let’s add prettier - hope you’ve heard of it since it’s the best thing that happened to code formatting in a while.

yarn add prettier --dev

We can pass arguments to the prettier script directly but I’m fan of config files, so we’ll create a .prettierrc file in the project root directory:

// .prettierrc
{
  "singleQuote": true,
  "tabWidth": 2,
  "trailingComma": "es5"
  // other available options: https://prettier.io/docs/en/options.html
}

Prettier will format all staged files on the commit so they follow a code convention defined inside the .prettierrc.

// package.json
{
  // ...
  "lint-staged": {
    "*.{js,md,css,scss,html}": ["prettier --write"]
  }
}

Time to lint our .js files, we can easily do that with eslint.

yarn add eslint --dev

We will define a config file again, this time the eslintrc.json:

// eslintrc.json
{
  "extends": "eslint:recommended",
  "env": {
    "browser": true,
    "commonjs": true,
    "node": true,
    "es6": true
  },
  "parserOptions": {
    "ecmaVersion": 2018
  },
  "rules": {
    "no-console": 2, // using console.log() throws error
    "curly": "warn" // enforce usage of curly braces, if(foo) foo++ will throw warning
  }
}

We need to define a special rule that will be triggered for .js files only. eslint will prevent committing if error is thrown.

// package.json
{
  // ...
  "lint-staged": {
    "*.{js,md,css,scss,html}": ["prettier --write"],
    "*.js": ["eslint --fix"] }
}

As the final step I’ll show you how to run relevant unit tests (relevant to committed files) and prevent commit if some of them are failing.

yarn add jest --dev
yarn add eslint-plugin-jest --dev

We should add previously installed jest plugin to our eslint config file so we eliminate eslint errors on .spec.js files.

// eslintrc.json
{
  "extends": ["eslint:recommended", "plugin:jest/recommended"], "env": {
    "browser": true,
    "commonjs": true,
    "node": true,
    "es6": true
  },
  "parserOptions": {
    "ecmaVersion": 2018
  },
  "rules": {
    "no-console": 2,
    "curly": "warn"
  },
  "plugins": ["jest"]}

Now extend lint-staged script:

// package.json
{
  // ...
  "lint-staged": {
    "*.{js,md,css,scss,html}": ["prettier --write"],
    "*.js": ["eslint --fix", "jest --bail --findRelatedTests"] }
}

--bail will skip execution of other tests when first test fails and --findRelatedTests is pretty self-explanatory 😁.

To demonstrate how this works we can create two files test-file.js and test-file.spec.js

// test-file.js
function sumTwoNumbers(a, b) {
  return a + b
}

module.exports = sumTwoNumbers

We’re intentionally making the unit test fail so we can see commit failing:

// test-file.spec.js
const sumTwoNumbers = require('./test-file')

it('should sum two numbers incorrectly', () => {
  const result = sumTwoNumbers(2, 3)

  expect(result).toBe(6)
})

commit-msg

There are only two hard things in Computer Science: cache invalidation and naming things

This rule applies to commit messages also, we’ve all seen or written commits like this in past:

git log --oneline

7c1f5c5 final fix
93393a0 aaaaa
3626b1d TEST WIP
45bc996 small css fix
29b2993 css final final fix
a2f6e18 lol
3ae828c UNIT TESTS ADDED WOO

This is an extreme example but it perfectly shows how we can’t make a clear conclusion about what is going on in a particular commit.

If we check history of commit messages created during previous examples:

git log --oneline

2c1f5c5 feat: add jest testing
85bc9g6 refactor: reformat html file

Much cleaner right? This commits follow Conventional Commit convention created by Angular team.

In general the pattern that commit message should follow mostly look like this:

type(scope?): subject #scope is optional

Some of common types are:

feat - commit adds a new feature.
fix - commit fixes a bug.
docs - commit introduces documentation changes.
style - commit introduces code style change (indentation, format, etc.).
refactor - commit introduces code refactoring.
perf - commit introduces code performances.
test - commit adds test to an existing feature.
chore - commit updates something without impacting the user (ex: bump a dependency in package.json)

So, now when we know this, it’s perfect time to introduce commit-msg hook where we’ll check if commit message respect this rules before we commit.

First we want to install commitlint, something like eslint just for commit messages.

# install commitlint cli and conventional config
yarn add --dev @commitlint/{config-conventional,cli}

Of course we need to create another config file, .commitlintrc.json, the last one I promise! 🤞

// .commitlintrc.json
{
  // Extend previously installed config
  "extends": ["@commitlint/config-conventional"]
}

Now we can extend hooks property inside the package.json:

// package.json
    // ...
    "husky": {
        "hooks": {
            "pre-commit": "lint-staged",
            "commit-msg": "commitlint -E HUSKY_GIT_PARAMS" }
    }
    // ...

Quick recap of what we learned today:

lint-staged inside the pre-commit hook will take care of:

formatting all staged files via Prettier.
check all staged .js files for syntax errors via Eslint
check if relevant .spec.js unit test files are failing before we commit via Jest

commitlint inside the commit-msg hook will take care of:

enforce commit message to follow Conventional Commit rules via Commitlint.

Holy Grail of JavaScript resources

Vladimir Simonovski — Sat, 04 Jan 2020 00:00:00 +0000

Following list* represents carefully selected resources/tutorials/articles related to JavaScript which can vastly help with clarification of confusing topics or improve JavaScript knowledge in general.

Legend

📚 - book

📃 - article/documentation

🎥 - video tutorial / tech talk / presentation

💸 - premium

Resources

📚 YDKJS - I told everything in my previous blog post.
📃 MDN Web Docs - Built by Mozilla, suitable both for complete beginners and industry experts.
💸🎥 JavaScript: Understanding the Weird Parts - Course by Tony Alicea, first 3.5hrs are freely available on YouTube
📃 Visualized prototypal inheritance - Visualization is awesome!
🎥 __proto__ vs prototype - Great explanation by Fun Fun Function, I can recommend his whole yt channel.
🎥 What the heck is the event loop anyway? - Tech talk from JSConf EU, must watch.
🎥 In The Loop - Tech talk from JSConf Asia, slightly more detailed video on async JavaScript, thanks @maleksandar for digging this up! 🍻
🎥 Why 0.1 + 0.2 === 0.30000000000000004 - IEEE754 standard in JavaScript explained
📃 33 Concepts Every JavaScript Developer Should Know - Really comprehensive list of resources.
📃 Awesome Javascript - A collection of awesome browser-side JavaScript libraries, resources and shiny things.
📃 Learny/Javascript - Great friend of mine @zsevic has similar list that is definitely worth taking a look
🎥 cssgrid.io - free css grid tutorial by Wes Bos
📃 codepip.com/games/grid-garden/ - free CSS Grid game by https://codepip.com/
🎥 flexbox.io - free flexbox tutorial by Wes Bos
📃 flexboxfroggy.com/ - free flexbox game by https://codepip.com/
🎥💸 Wes Bos Courses - one of premium content creators I respect the most, I have watched almost all of his premium course and every single of them was a game changer.

Web Dev YouTube channels

Miscellaneous

Web Gems - Webgems is a goto place for devs and designers to find new resources and more
CSS Tricks - Plenty of advanced css tutorials
Good UI/UX - Practical tips to make UI/UX better
codewars.com - Thousands of programming challenges in different programming languages

Stay up to date

r/webdev - Subreddit dedicated to Web Dev, you can easily find subreddit dedicated to your favorite framework also such as r/reactjs or r/angular2.
DevTo - Daily dose of really good, mostly web dev related, articles.
HackerNoon - -||-
JavaScript Weekly - the best JavaScript related newsletter out there.
Syntax.fm - one of the best WebDev podcasts by Wes Bos and Scott Tolinski.

* List like this can never be finished and will constantly be under construction 🚧, if you have some awesome resource to share, feel free to create PR or issue on repository where this blog is hosted.

YDKJS

Vladimir Simonovski — Tue, 13 Dec 2016 00:00:00 +0000

You Don’t Know JavaScript, is a great book series by Kyle Simpson about JavaScript core mechanisms. Unfortunately it’s harsh truth for most of Web Developers.

While JavaScript is perhaps one of the easiest languages to get up and running with, its eccentricities make solid mastery of the language a vastly less common occurrence than in many other languages. Where it takes a pretty in-depth knowledge of a language like C or C++ to write a full-scale program, full-scale production JavaScript can, and often does, barely scratch the surface of what the language can do.

I completely agree. Also, one big problem of newcomers to JavaScript is expecting from JavaScript to behave like some other programming language, however, JavaScript has its own set of ideas and ways of solving stuff, some of them are bad some of them are good and most of them are awesome.

Initial idea was to cover all books from YDKJS series, I realized it would be “reinventing the wheel” most of the time so I decided to cover only Up & Going with some extra examples. Following text represents brief summary of topics covered deeply in other YDKJS books, article is not substitute for reading all YDKJS books , main purpose is to make you more interested in YDKJS book series and javascript itself.

Types

JavaScript is loosely typed, this doesn’t mean JavaScript has no types, you just don’t need to write them.

The following built-in types are available:

string
number
boolean
null and undefined
object
- function
- array
- date
- regExp
symbol

You can check type of variable with typeof operator. You can call it as typeof(variable) too.

let a

console.log(typeof a) // "undefined"

a = 'Some text'

console.log(typeof a) // "string"

a = 42

console.log(typeof a) // "number"

a = true

console.log(typeof a) // "boolean"

a = nullconsole.log(typeof a) // "object" <- Caution!
a = undefined

console.log(typeof a) // "undefined"

a = {
  b: 'c',
}

console.log(typeof a) // "object"

This probably work as you expect, but again, be careful typeof(null) returns an object, so for an example if you want to check if some variable is an object you can do it like this:

let object = {}
let falseObject = null

function isObj(arg) {
  return typeof of === 'object' && arg !== null
}

console.log(isObj(object)) // true
console.log(isObj(falseObject)) // false

Objects

In JavaScript, an object is a standalone entity, with properties and type. Compare it with a car, for example. A car is an object, with properties. A car has a color, a design, a type, number of doors etc. The same way, JavaScript objects can have properties, which define their characteristics.

You can access object properties in two way, . ( dot notation ),

let ShibaInu = {
  legs: 4,
  race: 'Dog',
  sex: 'Male',
}

ShibaInu.legs // 4
ShibaInu['race'] // "Dog"

Objects are passed by reference, not by value.

let objA = {
    prop: "Some property value";
}

let objB = objA; // objB now "points" to objA object

objA.prop2 = "Another property value";

objB.prop2; // "Another property value"

More information about JavaScript objects later on.

Arrays

An array is an object that holds values (of any type) not particularly in named properties/keys, but rather in numerically indexed positions. For example:

let arr = [
    "1",
    23,
    { a : "b", c : "d" },
    function() { console.log("Hi!")
];

arr[0]; // "1"
arr[3](); // "Hi!"

Because arrays are objects, they can also have properties, including the automatic updated length property.

// arr from previous example
console.log(arr.length) // 4

arr.returnFirst = function() {
  return this[0]
}

arr.returnLast = function() {
  let len = this.length
  return this[len - 1]
}

arr.returnFirst() // "1"
arr.returnLast() // function () { ... }

// returnLast() returns function since last element of arr is a function
// we can invoke it with another set of ()
arr.returnLast()() // "Hi!"

Functions

JavaScript implements a first-class functions. This basically means that you can treat functions as any other type. You can pass them around, you can declare them inline, you can return them from other functions etc..

Functions, as many other things in JS, are objects. So like in case with Array they can have properties too. More details about functions later on, for now here is small example:

function ultimateQuestionOfLife() {
  return 42
}

ultimateQuestionOfLife() // 42

Comparing values

You can compare values with one of following operators:

==
!=
===
!===
Object.is() (ES6)

Result of any comparison is boolean value, true or false. Main difference between == and === is coercion. == allow coercion and === don’t.

It’s handy to know what evaluates to true and false before comparing values.

Falsy values:

"" - empty string
0, -0, NaN
null, undefined
false

Truthy values:

"hello"
42
true
[]
{}
function bar() { ... }

Variables

Valid name: must start with a-z, A-Z, $ or _, It can contain any of those characters plus the numerals 0-9.

Hoisting

Wherever a var appears inside a scope, that declaration is taken to belong to the entire scope and accessible everywhere throughout. Metaphorically, this behavior is called hoisting, when a var declaration is conceptually “moved” to the top of its enclosing scope. Technically, this process is more accurately explained by how code is compiled, but we can skip over those details for now.

Consider this example:

var a = 2

foo() // works because foo() declaration
// is hoisted

function foo() {
  a = 3
  console.log(a) // 3
  var a // declaration is hoisted
  // on top of foo()
}

console.log(a)

Or:

var a = 42

function bar() {
  console.log(typeof a) // "function"
  a = 23
  function a() {}
  return a
}

bar()
console.log(a) // 42

So function a() is hoisted on top of function function bar(), then we give it a value of 23 so it becomes a number, and finally we return it. Because of this behavior the global a variable stays unchanged.

When you declare a variable it’s available anywhere in that scope. JavaScript used to have only function scope, meaning creating function creates new scope. ES6 changed that introducing the let keyword, using let one can declare block scope.

function bScope() {
  var a = 10
  if (a >= 10) {
    let a = 5
  }
  console.log(a)
}

function fScope() {
  var a = 10
  if (a >= 10) {
    var a = 5
  }
  console.log(a)
}

bScope() // 10
fScope() // 5

Strict mode

ES5 added “strict mode” to the language. Strict mode tightens the rules for certain behaviors. In general using strict mode, your code will become “safer place”, this doesn’t mean your code will become error proof or perfect, but it will be one step closer to that.

function foo() {
    "use strict";
    // this code is in strict mode
    function bar() {
        // this code is in strict mode
    }

Or:

'use strict'
// this code is in strict mode
function foo() {
  // this code is in strict mode
  function bar() {}
}

Strict mode is disallowing the implicit auto-global variable declaration from omitting the var keyword.

function foo() {
  'use strict'
  a = 42 // var missing, ReferenceError
}

foo()

Immediately Invoked Function Expressions (IIFEs)

IIFEs can be very usefull, let’s see some examples:

(function IIFE() {
  console.log('Hi from IIFE!')
})()

// "Hi from IIFE!"

The outer ( .. ) that surrounds the function is just a mechanism needed to prevent it from being treated as a normal function declaration. The final () on the end of expression is what executes the function.

Creating IIFE you also create new variable scope, so you can use IIFE to do something like this:

var a = 42
(function IIFE() {
  var a = 10
  console.log(a) // 10
})()

console.log(a) // 42

IIFEs can also have return values:

var x = (function IIFE() {
  return 42
})()

console.log(x) // 42

Closure

Closures are functions that refer to independent (free) variables (variables that are used locally, but defined in an enclosing scope). In other words, these functions ‘remember’ the environment in which they were created.

Little motivation to learn and understand closures, recently I took couple of interviews and in 90% of them I had task to write function that sums two number, function must be called in this way: sum( arg1 )( arg2 )

Solution:

let sumES6 = x => {
  return y => {
    return x + y
  }
}

console.log(sumES6(2)(3)) // 5

If you are not familiar with ES6 arrow functions, here is equivalent ES5 example:

let sumES5 = function(x) {
  return function(y) {
    return x + y
  }
}

console.log(sumES5(2), 3) // 5

Because of this mechanism, we can set one argument, and pass other argument later on. In our example we double invoke over sumES6 function. On first invoke we return reference to inner function, on second invoke we return x + y value. Closure give us acess to x value we passed in first invoke.

Module pattern

The most common usage of closure in JavaScript is the module pattern. Modules let you define private implementation details (variables, functions) that are hidden from the outside world, as well as a public API that is accessible from the outside.

Consider the example:

function Employee() {
  let name, surname

  function returnSalary(nm, srnm) {
    name = nm
    surname = srnm

    // connect to a database
    // return salary or smth. similar here ...
  }

  let publicAPI = {
    salary: returnSalary,
  }

  return publicAPI
}

// create a `Employee` module instance
let john = Employee()

john.salary('John', 'Doe')

So, the publicAPI object is returned after Employee is invoked, john will have access to sallary property of that object, that will again return inner returnSallary function.

this keyword

this is very specific mechanism in javascript and it’s value mainly depends on context of execution.

If a function has a this reference inside it, that this reference usually points to an object. But which object it points to depends on how the function was called. It’s important to realize that this does not refer to the function itself, as is the most common misconception.

function foo() {
  console.log(this.bar)
}

let bar = 'global'

let obj1 = {
  bar: 'obj1',
  foo: foo,
}

let obj2 = {
  bar: 'obj2',
}

// --------

foo() // "global"
obj1.foo() // "obj1"
foo.call(obj2) // "obj2"
new foo() // undefined

There are four rules for how this gets set, and they’re shown in those last four lines of that snippet.

foo() ends up setting this to the global object in non-strict mode — in strict mode, this would be undefined and you’d get an error in accessing the bar property — so “global” is the value found for this.bar.
obj1.foo() sets this to the obj1 object.
foo.call(obj2) sets this to the obj2 object.
new foo() sets this to a brand new empty object.

I will stop here. For further informations consider looking this YDKJS books overview.

I hope you enjoyed this article and that you’re more interested in learning javascript than you were before reading this article. Remember: