Forem: Vasily Malykhin

SemVer - Magic version 0

Vasily Malykhin — Tue, 06 Apr 2021 19:16:44 +0000

SemVer

Semantic Versioning defines a package version format and a set of rules that should be used when the package updates.

Under this scheme, version numbers and the way they change convey meaning about the underlying code and what has been modified from one version to the next.

A brief intro to SemVer: you can specify a version of a package using three groups of numbers: major.minor.patch. When you create a new version of your package, you should:

Increment major if you introduced a breaking change.
Increment minor if you added functionality in a backward-compatible manner.
Increment patch if you made a backward-compatible bugfix.

This is pretty much it, although in documents you can find more details.

Version ranges

When you work with package managers which rely on semver (e.g. NPM), you can declare specific versions of dependencies or version ranges, which would allow you to update dependencies easier.

For example, you can use the caret(^) symbol to tell the package manager that all compatible versions are allowed:

// package.json
"dependencies": {
  "react": "^16.0.0"
}

The above means that all versions of react up to (but not including) 17.0.0 are allowed. So when a new version of react is out, you can run npm update and it will download an updated version of it, update your package.json and a lock file.

Magic zero

But there is an exception for packages with major version equal to zero, e.g. 0.1.2.

Major version zero (0.y.z) is for initial development. Anything MAY change at any time. The public API SHOULD NOT be considered stable.

Technically, it is legitimate to introduce breaking changes, updating the minor digit of the package version. So, versions 0.1.2 and 0.2.0 won't be compatible.

To prevent potential breaking changes, when you do a minor update of a dependency, NPM treats versions a bit different:

Allows changes that do not modify the left-most non-zero element in the [major, minor, patch] tuple. In other words, this allows patch and minor updates for versions 1.0.0 and above, patch updates for versions 0.X >=0.1.0, and no updates for versions 0.0.X.

So, if you have a dependency ^0.1.2, npm update won't update it to 0.2.0, because only patch updates are allowed.
I didn't know this subtlety before and when an automatic update didn't work, I thought that it was due to some bug in NPM CLI :) Even worse, I updated the dependencies manually... Even though we had a lot of tests, how on Earth didn't I break anything?!

Anyways, if you depend directly or transitively on various 0.x.y versions of the same package, you can't do much. But as a package author, if you introduce a backward-compatible update to 0.x.y version, you'd better update patch instead of minor. That way the update process would be more streamlined for the package consumers.

P.S.

Online semver calculator - https://semver.npmjs.com/
Discussion related to pre-releases and magic zero - https://github.com/semver/semver/issues/221

Eslint vs Performance

Vasily Malykhin — Sat, 03 Apr 2021 15:33:30 +0000

Nowadays, eslint is a very popular tool in the frontend world. It helps you to enforce different code style rules, prevent bugs, and encourage your team to use best practices as you write code.

Eslint is completely pluggable and you can add as many rules as you wish, and of course, write your own rules. As you start seeing the benefits eslint gives you, it is become very tempting to use each and every rule that you can reach out to.

But beware! Keep in mind, that with every rule you accumulate the amount of work that needs to get done whenever you lint your code, be it a local development or a part of a CI.

To get some insights about time spent on every rule you can use a special environment variable TIMING=1. It will trigger the display of the ten longest-running rules, along with their individual running time and relative performance impact (docs).

Take a look at the timing information on one of the projects I'm working on:

Rule                                    | Time (ms) | Relative
:---------------------------------------|----------:|--------:
import/no-restricted-paths              | 94633.358 |    72.2%
@typescript-eslint/no-floating-promises | 18576.419 |    14.2%
react/no-multi-comp                     |  4629.594 |     3.5%
@typescript-eslint/no-redeclare         |  2634.454 |     2.0%
lodash/callback-binding                 |  1272.849 |     1.0%
@typescript-eslint/naming-convention    |  1209.871 |     0.9%
lodash/collection-return                |   885.415 |     0.7%
lodash/no-unbound-this                  |   669.923 |     0.5%
lodash/collection-method-value          |   668.716 |     0.5%
lodash/no-extra-args                    |   569.119 |     0.4%

More than 90 seconds spent on checking a single rule... A little bit too much, isn't it? :)

In this particular example, the TIMING report revealed a performance bottleneck and pushed us to contribute to a third-party eslint plugin we used and fix it eventually.

In addition to obvious performance issues, you might notice that a significant amount of time is wasted on rules that you can live without. For example, most of the code-style-related rules could be replaced with prettier. Some rules just don't give you that much to use them, e.g. react/no-multi-comp in our case.
As for me, I prefer to follow this advice:

Look at every linting rule and think: “Does this rule ~~bring me joy~~ help me find bugs?” If not, TURN IT OFF.

But I would add: start with ten the longest-running rules if your goal is to speed up linting.

Fix a transitive npm dependency vulnerability

Vasily Malykhin — Fri, 29 May 2020 08:50:09 +0000

Thanks to community, from time to time, npm reports about vulnerabilities found amongst the installed dependencies. Our team works on a SPA based on react, webpack, storybook, babel, and so on, pretty basic setup nowadays. We strive to keep the number of vulnerabilities as small as possible. But sometimes it is not that easy to fix them.

The transitive dependency or, in other words, the indirect one might be located very deep in the tree. For example, on March 6th, 2020 a ~~kind of vulnerability~~ vulnerability in kind-of package had been found. All of a sudden, we ended up with more than 38000 of low-level vulnerabilities, reported by npm audit.

We didn't have it in our package.json file, but obviously it was used by a ton of packages deep in the tree. For example, take a look at this path to kind-of:



jest>jest-cli>@jest/core>@jest/reporters>jest-runtime>jest-config>@jest/test-sequencer>jest-runner>jest-jasmine2>@jest/environment>@jest/transform>jest-haste-map>jest-util>@jest/fake-timers>jest-message-util>micromatch>nanomatch>kind-of

The standard recommendation given by the npm audit is to run



npm update  package-name --depth=N

To be honest, I haven't seen it working yet. Sometimes this command does nothing, sometimes it does "so much" that it hangs forever.

So, the only way to fix it for us was to do it manually. Exploring package-lock.json, we noticed that a vulnerable version (6.0.2) was installed multiple times by different packages. In order to get rid of the vulnerabilities, we had to update all occurrences of kind-of:

npm install -D kind-of@6.0.2 - install 6.0.2 to remove duplicates on the next step
npm dedupe - remove duplicates of 6.0.2
npm update kind-of - fix vulnerability upgrading to 6.0.3
npm uninstall kind-of - remove the direct dependency

After these manipulations, we saw a much better picture:

In that case, it was rather simple to identify duplicates and find out how to dedupe dependencies. But in more complex cases we find it very useful to use discovery.js. See it in action here

P.S.
Don't pay attention to the rest of the vulnerabilities. We are already working on them ;)