Category Archives: Web

What did I do in 2018?

Photo by chuttersnap

2018 is ending, I will do a quick review of the personal projects I worked on the last 12 months, in order to keep track of what I accomplished over the last year.


I worked on 3 main personal projects over this past year:

topheman/npm-registry-browser 🔗

There are lots of great resources on React (tutorials, blog posts, books, videos …), but most of them focus on a specific problem. Today, making an app is a lot about picking and putting building blocks together:

  • choosing and setting up external libraries (UI kits, state management, http clients, routers …)
  • enabling code quality good practices (linting, testing, git hooks, cis …)
  • automation / dev pipeline

The hard part is to put this all together. This is the goal of this project: provide a well-documented example of a front-end app with real-world features and constraints.


topheman/docker-experiments 🔗

The goal of this project is to let you discover docker/docker-compose with a simple use case in development, production (local kubernetes) and CI. I provide a highly documented README which I use myself as a reference.

The project itself ships:

  • a frontend made with create-react-app, running in a nodejs container for development
  • a very simple api made in go (the challenge was also not to have everything in JavaScript)
  • nginx setup as reverse proxy on the production image


topheman/react-fiber-experiments 🔗

At the time I’m writting this post, data fetching with Suspense is still not yet enabled in React (not even in alpha versions), Suspense is only available for code splitting (v16.8.0-alpha.1).

In march 2018, Dan Abramov presented for the very first time React Suspense. A month later, Andrew Clark made an other talk about Suspense, more oriented on placeholders.

In august 2018, Ryan Florence made a talk about route recalculating, where he presents how @reach/router can work with React Suspense.

In september 2018 (at this time, react was in v16.5.0), I decided to make a project based on the data fetching and code splitting features of Suspense to better understand the benefits of those features and expose them to other developers (since this will be a game changing for data fetching in React).



This year I made a few talks at local meetups:

Utils / Boilerplates

  • topheman/delay-proxy: A little development tool that lets you emulate slow network connections
  • topheman/my-react-app-starter: create-react-app is a great toolkit which removes a lot of boilerplate to manage. I added a few features that I was missing like: eslint/prettier/precommit hook, generate changelog, deploy task …
  • topheman/fullstack-setup: research repo about formatting automation


This year, I worked a lot on React (I like this library and I’ve been working with it for almost 4 years). I also got deeper into docker with topheman/docker-experiments (every year, I like to pick a technology outside of JavaScript and do a little more than just a Hello World 😉 ).

The main guideline I followed this year was to ship projects that take in account the constraints you would have developing in team (even if I was working alone):

  • formatting and linting enforced at precommit-hook: thanks to prettier and eslint, no more discussion about code style on PRs!
  • dev experience: accessible npm tasks install / start / build / test / deploy … more specific ones should be documented
  • unit tests
  • end to end tests: thanks to Cypress (read advanced setup)
  • CI: automatic deployment

This is the first time I’ve done a screencast. It was an interesting experience (doing it in english, not in french 😉 ).


In 2019, I will try TypeScript – I already used it a little 3 years ago in topheman/angular2-sandbox to test angular@2 and ngrx, but now is definitely the time to check it out.

Pourquoi réaliser topheman/npm-registry-browser ? vidéo talk (fr)

Dans un post précédent, j’ai présenté la démarche que j’ai suivie pour mon dernier projet en React topheman/npm-registry-browser.

Il y a quelques jours, j’ai fait un talk à ce propos au meetup ReactJS chez Toucan Toco. Le meetup était enregistré, vous pouvez visionner mon talk (30min) en première partie de la vidéo :

Ressources :

A project to help getting into making React apps

Why I made topheman/npm-registry-browser

In software development, a lot of great quality resources are available, often for free. I’ve been getting feedbacks from developers – at work, online, at meetups – who shared that the hard part is not finding the knowledge but picking one library over an other or putting them all together.

Tutorials explaining a specific problem are all over there, what’s missing is projects examples / courses with a wider point of view.

This is what I decided to do in my latest project: topheman/npm-registry-browser. I respect some constraints that you would get, developing a real-world application, such as:

  • external API calls
  • using external libraries (UI kits, router, http clients …)
  • project setup for development with teams
  • code quality (linter, code formatting)
  • tests (unit / end to end)
  • automation / dev pipeline

The project itself is a Single Page Application that lets you search for packages in the npm registry and show details for each one of them such as the readme, the versions, the stats … In fact, this project is just an excuse to expose how to put together all those technologies I mentioned above.

The source code is available on github. You can test a demo online. I will be adding more features in the next weeks.


PS: This project is based on create-react-app and remains unejected. It was a constraint I imposed myself from the start. I never used CRA before (I have my own webpack starter-kit), so I wanted to test it to be able to tell what’s possible to do with it and what is not.

PPS: I chose not to use Redux, at least, not in that first version because … You might not need Redux (explanation) …

📺 Watch video of the talk (fr)

ES6+ code coverage with Babel plugin


Running unit tests against an ES6+ source code base has now become an almost trivial task, thanks to Babel and all the ecosystem around it. There are a lot of good resources explaining how to do that, with different tools and frameworks.

On the other hand, code coverage on this kind of tests is a rather less covered subject …

If you apply regular code coverage solutions to that case, you end up with reports based on the transpiled code, not your original source code in ES6+, which isn’t really relevant …

Here comes isparta

This problem was solved by isparta, a code coverage tool for ES6+, using Babel, which provides code coverage reports using istanbul (which is also a code coverage tool … 😉 more infos here).

Using isparta, you can generate code coverage from unit tests on ES6+ source code base, directly against your original source code (not the transpiled one). This works great, combined with tools like karma-coverage, you can output coverage reports under any format (html, lcov … that can be processed by various tools/services like Jenkins or …).

isparta not maintained anymore

No Maintenance Intended

About two weeks ago, @duglasduteil added the “No Maintenance Intended” badge to his module. This should remind us that behind every open source project there are developers maintaining them (most of the time on there free time).

So, now may be the time to find a replacement for isparta … I was looking for an alternative for a few days when I eventually ended up on twitter with @kentcdodds who mentionned dtinth/babel-plugin-__coverage__.

ES6+ code coverage using a Babel plugin

Since Babel v6, you can make your very own plugins that can do much more than simply transpile ES6+ to ES5.

Babel is a generic multi-purpose compiler for JavaScript. More than that it is a collection of modules that can be used for many different forms of static analysis.

Babel Plugin Handbook

That’s what @dtinth has done with babel-plugin-__coverage__. He made a babel plugin that instrument your code, injecting metadata that will be processed by istambul (which is used under the hood by karma-coverage and other coverage report tools).

The great thing is that, since you go through Babel anyway to transpile your source code, the only thing you have to do to get those infos to feed tools like karma-coverage (or any istambul-based coverage reporter) is to activate this plugin in your .babelrc file …

Using a babel plugin for coverage is a no-brainer.


You won’t have to add complex configuration or tools anymore. @dtinth‘s plugin is 300 LOC, it’s his first babel plugin that he made over two nights. As far as I have tested it, it works very well.

This is clear that using a babel plugin for that kind of purpose is the right way to proceed. Since it’s becoming easier to setup, we might see more projects using ES6+ including code coverage reports in a near futur.

You can see an example of setup on my project topheman/react-es6-redux.

Checkout it out

How I became a JavaScript developer …


I’ve been doing JavaScript for some time now, and like a lot of us, until a few years ago, it was mostly limited to jQuery … Till I watched this podcast of Paul Irish where he takes the source code of jQuery (1.4.2 :D) and breaks it down explaining things like closures, IIFEs, module pattern …

That’s when I realised I wasn’t writing JavaScript at all but jQuery and I chose to really learn the language. At that time, I was mainly developing in php (Zend framework) / MySQL & jQuery.

I really enjoyed discovering this whole new part of JavaScript. I remember giving a talk to the developers in my company about JavaScript (I did some livecoding of a plugin in jQuery, explaining every bits of the code). My co-workers were always teasing me about how JavaScript was not even a real language, that it had no concepts of inheritence or object oriented programming and that I was insane to waste my own time learning it …

But then, NodeJS came along … and some other cool stuffs …

I eventually quit this company (I learned a lot on web development there and met great people, but it was time to change) to work on a full-js job.

Since then, I never stopped learning, experiencing new stuff on personal projects … At some point I started publishing some code on github, posting articles on my blog, answering questions on stackoverflow (giving back to the community) …

For the last three years, I’ve seen a lot of changes within the JavaScript ecosystem. With the new ECMAScript standards and everything, it’s not going to stop. I’ll do my best to keep up to date, not only because I have to but because I enjoy it !

And you, how did you become a JavaScript developer ?…