The CITGM Diaries:

things break in mysterious and beautiful ways

With your host @MylesBorins

NodeConf Barcelona 2017

Hola

My Name is Myles

itsa me!

I am gainfully employed by Google as a Developer Advocate

Focusing on the Node.js ecosystem running on GCP

Google Clud Platform
The opinions expressed in this talk are solely my own

Dear Diary

Today we broke npm

It turns an api deprecated in 2010

was never actually deprecated

So it was decided to deprecate it

but only with a warning

The change landed

It broke npm on master

Due to the way in which graceful-fs works

A short term solution was made to give people time

How were we to know

that a warning

would break the world

CITGM Saved the day!

So what exactly is CITGM?

The acronym stands for

Canary in the Gold Mine

It is the Smoke testing utility

That we use in the Node.js Project

To make sure we don't break your code!

and that the ecosystem is healthy

citgm grabs the source code of a named module

runs npm install and npm test

it then reports results

We run CITGM in CI

Building a specific sha

in the node tree

running the test suite of a specific module

and reporting the results

it has a logger with various verbosity levels

it totes passed!such verbosity!

Results can be published as:

markdown

nice markdown!

Results can be published as:

tap

tap it in

Results can be published as:

xunit

xunit reporter

citgm-all

Currently testing

86 modules

This includes:

core ecosystem modules

This includes:

modules for streams

This includes:

modules for the front end and tooling

This includes:

natively compiled modules

Why exactly are you doing that?

Every test in the Node.js ecosystem

is an integration test for core

By running ecosystem tests against a specific version of node

We can find out what is going to break, before it breaks

We run citgm-all in CI

for all semver-major changes and release

if it doesn't pass the change doesn't land

show some images of our CI in jenkins

How does it work?

We do a lot of wrapping

npm view

we wrap that

npm pack

we wrap that

npm install

we wrap that

npm test

we wrap that

Why would you use so many child processes?

npm already does all this stuff!

Every build we do in CI already has it!

The npm cli api is not going to change on us

Dear Diary

Today Body Parser Broke

Before Change

> var parse = require('querystring').parse;
> parse('%p=123', undefined, undefined,
>  {maxKeys: Infinity}).length;
< 1

After Change

> var parse = require('querystring').parse;
> parse('%p=123', undefined, undefined,
>   {maxKeys: Infinity}).length;
< 0

Sometimes a patch

is much more disruptive

than it seems at first

Dear Diary

Today we accidentally broke gulp

Now that v7 is coming

we decided to revert the hack in fs

After failures on citgm

We decided to do an ecosystem scan

It broke 5%

of all modules on npm

we got the list down

but gulp 3 was still affected

In fact, the gulp ecosystem

was not an insignicant number of the broken packages

To avoid breaking the world

I did a little raggae

Unfortunately

it was not enough

We almost gave up

Until Isaacs came up

with an elegant solution that backported

As of Node v7 this will no longer be a problem

Dear Diary

Even though we broke lots of stuff

Most people didn't notice

That is a reason to celebrate

Thank You

best episode ever

@MylesBorins

@MylesBorins