DEV Community: Antoine Lehurt

Speed up your CircleCI pipeline by using the RAM disk

Antoine Lehurt — Thu, 21 Jan 2021 09:31:29 +0000

During a presentation—held internally at Acast by my
colleague Daniel Grefberg—I discovered a one-line change that reduced by 2 minutes the execution time of my current project's CI pipeline.

- working_directory: ~/my-project-name
+ working_directory: /mnt/ramdisk/my-project-name

CircleCI allows us to mount the project on the RAM disk and use it as a "temporary file storage paradigm." That means, when caching a project's dependencies, CircleCI will use the RAM disk instead of the disk drive.

When working on a Node.js project, it is common to cache the node_modules folder. It allows us to re-use it in the other jobs to avoid running the install command every time. On paper, that should be faster than running npm ci (or yarn install --frozen-lockfile) for each job, but that's not necessarily the case. It usually takes ~2 minutes to restore the cache of ~400MB. This time is mainly taken for decompressing the thousands of files from the folder on the disk. But, this step gets down to ~20 seconds by moving it to the RAM disk.

This change is a quick win to save a few minutes for running our pipeline. The only drawback is that we are limited to the RAM capacity—defined by the job's resource_class attribute. By default, it runs on a 4GB RAM (medium resource class), so depending on our project and the dependencies' size, we might need to increase the resource class.

version: 2.1

aliases:
  - &default_image
    working_directory: /mnt/ramdisk/my-project
    docker:
      - image: cimg/node:12.20

  - &cache_key v1-cache-{{checksum ".circleci/config.yml"}}-{{checksum
    "yarn.lock"}}
  - &restore_cache
    restore_cache:
      keys:
        - *cache_key

jobs:
  initialize:
    <<: *default_image
    steps:
      - checkout
      - *restore_cache
      - run: yarn install --frozen-lockfile
      - save_cache:
          name: Save cache
          key: *cache_key
          paths:
            - node_modules

  test_unit:
    <<: *default_image
    steps:
      - checkout
      - *restore_cache
      - run: yarn test:unit --maxWorkers=2

How to keep small Pull Requests

Antoine Lehurt — Sun, 14 Jul 2019 12:00:00 +0000

Photo by @jdubs on Usplash

Pull Requests (or PRs) are an essential part of team collaboration. It helps to catch issues, spread knowledge, and it brings confidence in our changes. When reviewing code, the reviewers also take responsibility for the changes that will be merged. So, when opening a PR, it’s important to share as much information as possible. It helps the reviewers to recreate the mental model we had when working on the task (Why we did that change? How we did it? Why we did it that way?). The key is to keep our PRs small and focused. It’s fine to have a PR with several commits, and it’s even an excellent way to share the flow of our thoughts and changes. But the changes have the be related to the same goal. When PRs are significant, it’s harder to spot bugs, design flaws and the reviewers might feel overwhelmed. The worse case would be to approve the change without paying attention to it, which would defeat the initial purpose of working with PRs.

In this article, we will go through different scenarios to split a PR into smaller chunks.

Scenario 1: clean history, but too many unrelated changes

Before opening our PR, we realize that we could move some commits into a different PR. For instance, we created a new helper function on the way, and it will help reviewers to pay more attention to it.

$ git log
## branch: new-feature
* 8ee70d7 Commit 3
* b6a5da4 Add new helper
* d3b11d2 Commit 1

We will create a new branch from master and reuse the commit “Add new helper” using cherry-pick. And then create a PR for that new branch.

$ git log
## branch: new-feature

$ git checkout -b style-helper master
## branch: style-helper
$ git cherry-pick b6a5da4
$ git push origin

We can now go on GitHub and open the pull request.

The last step is to push new-feature to GitHub, but when we open the pull request, we need to change the base branch and use style-helper branch. (On GitLab it’s called the “target branch”.) We can check the commit history on the GitHub interface and see that “Add new helper” is not part of it. After merging style-helper PR, we should not forget to change the base branch tomaster before merging new-feature.

Scenario 2: need to split some commits

This time, we have mixed different changes in the same commit. We still want to create a different PR for our style helper, so we need to split that commit into multiple commits.

$ git log
## branch: new-feature
* 8ee70d7 Commit 2
* d3b11d2 Commit 1 <-- commit we want to split

The first step is to go back to “Commit 1” using rebase, and then we willreset that commit to split it using add --patch.

## branch: new-feature

git rebase -i d3b11d2^

Vim, or the editor defined in your gitconfig, will open and we specify which commit we want to edit.

pick 8ee70d7 Commit 2
e d3b11d2 Commit 1

We are now back at “Commit 1” and it’s now time to split it. We first need toreset the commit to put the change back in an unstaged state so we can later use add --patch.

$ git reset HEAD~
$ git add --patch

We follow the prompt and decide which hunk we want to stage using yes, no or edit.

$ git commit -m "Split 1"
$ git add --patch
$ git commit -m "Split 2: style helper"

We are now done with splitting the commit. We can complete the rebase.

$ git rebase --continue
$ git log
## branch: new-feature
* 8ee70d7 Commit 2
* 02dbeb3 Split 2: style helper
* cf4ca41 Split 1

We are at a similar stage as the first scenario, and we will go through the same steps for opening the two PRs.

Scenario 3: it’s a mess, let’s rewrite history

Sometimes things don’t go according to plan, and we end up with a spaghetti Git history. The best, in that case, is to rewrite it.

The first step is to find from which commit we want to start fresh.

$ git log
## branch: new-feature
* 255e8d5 Stuff 4
* 5c3fa7e Stuff 3
* deea3e8 Stuff 2
* 10a2b4a Stuff 1 <-- from here

$ git reset 10a2b4a^

Now everything is back to an unstaged state. We will commit the change we want to include in our first PR using add --patch. Then stash the rest to create a new branch and continue to commit from there and finally open our second PR.

## branch: new-feature

$ git add --patch
$ git commit -m "Commit 1"
$ git stash
$ git push origin

We can open the first PR using master as base branch.

Next, we create a new branch for the second PR.

## branch: new-feature

$ git checkout -b pr-2
## branch: pr-2
$ git stash pop
$ git add --patch
$ git commit -m "Commit 2"
$ git stash
$ git push origin

We can open the second PR using new-feature as base branch.

We repeat these steps until we don’t have anything left in the stage.

Conclusion

It might feel cumbersome to go through these steps, but I think it’s important to show empathy to the reviewers and put them in good condition.

These are the scenarios I have encountered to split a PR into smaller chunks, feel free to share a different way of doing.

Why I'm using react-testing-library instead of Enzyme

Antoine Lehurt — Fri, 14 Jun 2019 12:00:00 +0000

Enzyme has been my weapon of choice since 2016 for testing my React components. What I liked the most with Enzyme was the isolation of the component when testing it using shallow rendering. I could focus on testing the component behaviour and checking that the correct props were passed down to the children (mostly using snapshot testing). That allowed me not to have to mock the children components, for instance for root components, and have tests that run quickly. So, I was only testing at the unit level, each component separately, and tested the big picture using Cypress (end to end testing).

It’s only when I started to use React 16.8 (“The One With Hooks”) that I looked at other testing libraries. The main reason was the non-possibility to test custom hooks with Enzyme and not being able to use shallow rendering. Which led me to be more curious with other solutions and to dig into react-testing-library finally.

Issues with Enzyme

When rendering a component using Enzyme, it wraps the component and allows us to traverse the tree and access the component’s data (instance, props, state, children, …) using a rich API. But, great power comes great responsibility and being able to access internal state of the component (.state(), .setState(),.instance()) often leads to test its implementation. I saw it many times when working on a React codebase, sometimes because it’s “easier and faster than having to reproduce the user steps”. For instance, in a component that has buttons I used to search for a Button component and call its onClick prop instead of having to mount and simulate the click on that element.

wrapper
  .find('Button')
  .at(0)
  .prop('onClick')();

But, the test would break if we replace the Button with a component having similar functionalities or if we decide to move the button at a different index. It can get really complicated to work with this type of test, since every time you touch the implementation a test breaks. Which makes refactoring really painful. It’s not Enzyme faults per se, but giving access to the private properties to developers allow them to take shortcuts and test the implementation detail which results in brittle tests.

Different approach

React testing library has a different approach to testing than Enzyme. It’s closer to integration testing than unit testing. It renders the component and attaches it to the DOM. We only have access to the elements that are in the DOM. No internal state, no instance methods, just what the user can interact with. And that’s at the end the most important, we want to make sure that our code won’t break when it gets in the user’s hands. It helped me to rethink how and what I test when working on React components.

So far, it’s been a great experience:

I like that there is only one type of rendering, so I don’t need to think about it;
Tests are still fast to run. I was in the wrong impression that rendering the component on the DOM between each test would be more expensive;
The DOM utils are focused on accessibility (getByRole, getByAltText, etc);
I rely less on snapshot testing and test more individual elements (jest-dom is handy for that) so tests break less when I change an unrelated node element;
My test structure is very similar to what I used to do with Enzyme using a setup factory.

But, it also comes with some downside like having to mock children dependencies, for instance, if it fetches data on mount. So depending on the need, I might usejest.mock to mock a child component.

import { render } from '@testing-library/react';
import React from 'react';
import App from './App';
import SomeAppSection from './SomeAppSection';

jest.mock('./SomeAppSection');

SomeAppSection.mockReturnValue(<div>SomeAppSection</div>);

const setup = (props = {}) => render(<App logout={jest.fn()} {...props} />);

it('renders SomeAppSection', () => {
  const logout = jest.fn();
  const { getByText } = setup({ logout });

  getByText('SomeAppSection');
  expect(SomeAppSection).toHaveBeenCalledWith({ logout }, {});
});

In this example, I don’t want to have to deal with SomeAppSection behaviour since it will require me to have too many things to mock or keep track of when the component will change in the future. So, I fall back to what I used to do with Enzyme by mocking it away.

Great reads related to testing-library or testing in general:

React Hooks by example: useState, useCallback, useEffect, useReducer

Antoine Lehurt — Fri, 07 Jun 2019 12:00:00 +0000

Photo by @ckirby on Unsplash

In this article, we will touch upon how to use useCallback, useEffect,useReducer and useState hooks.

We will build a component that gives the user the ability to search for a list of users. The component will store the data about the request state (if it’s loading) and response (the user list or the error information). It will listen for the form submit event and call the backend with the input’s value to get the list of users. There are different ways to achieve it, such as using Redux, but we will keep it basic since we will focus on the hooks.

The class way (without hooks)

Using a class component, it could look like this:

class UserSearch extends React.Component {
  constructor(props, ...rest) {
    super(props, ...rest);

    this.state = {
      loading: false,
      error: undefined,
      users: undefined,
    };
  }

  componentWillUnmount() {
    if (this.request) {
      this.request.abort();
    }
  }

  handleFormSubmit = event => {
    this.setState({ loading: true });

    this.request = superagent.get(
      `http://localhost:8080/users/${event.target.elements.username.value}`
    );
    this.request
      .then(response => {
        this.setState({
          loading: false,
          users: response.body.items,
        });
      })
      .catch(error => {
        this.setState({
          loading: false,
          error,
        });
      });
  };

  render() {
    const { loading, error, users, searchValue } = this.state;

    return (
      <form onSubmit={this.handleFormSubmit}>
        {error && <p>Error: {error.message}</p>}

        <input type="text" name="username" disabled={loading} />
        <button type="submit" disabled={loading}>
          Search
        </button>

        {loading && <p>Loading...</p>}

        {users && (
          <div>
            <h1>Result</h1>
            <ul>
              {users.map(({ id, name }) => (
                <li key={id}>{name}</li>
              ))}
            </ul>
          </div>
        )}
      </form>
    );
  }
}

The functional way

We will refactor the UserSearch component step by step and introduce the hooks on the way.

We no longer need to use classes when we use hooks. The first step is to extract the render method into a function based component. We also inline the state and the event handlers, but currently, they don’t do anything.

const UserSearch = () => {
  const loading = false;
  const users = undefined;
  const error = undefined;

  const handleFormSubmit = () => {
    // TODO
  };

  return (
    <form onSubmit={handleFormSubmit}>
      {error && <p>Error: {error.message}</p>}

      <input type="text" name="username" disabled={loading} />
      <button type="submit" disabled={loading}>
        Search
      </button>

      {loading && <p>Loading...</p>}

      {users && (
        <div>
          <h1>Result</h1>
          <ul>
            {users.map(({ id, name }) => (
              <li key={id}>{name}</li>
            ))}
          </ul>
        </div>
      )}
    </form>
  );
};

Introducing hooks

useState

We can use the useState hook to store the different states we have in our component (loading, users, error). useState takes the initial value as a parameter and returns a tuple of the state value and a function to update the value.

const [value, setValue] = useState(initialValue);

Let’s update our states using setState. Currently, we only initialize the states, but we need to implement the logic.

const UserSearch = () => {
  const [loading, setLoading] = userState(false);
  const [users, setUsers] = useState();
  const [error, setError] = useState();

  const handleFormSubmit = () => {
    // TODO
  };

  return (
    <form onSubmit={handleFormSubmit}>
      {error && <p>Error: {error.message}</p>}

      <input type="text" name="username" disabled={loading} />
      <button type="submit" disabled={loading}>
        Search
      </button>

      {loading && <p>Loading...</p>}

      {users && (
        <div>
          <h1>Result</h1>
          <ul>
            {users.map(({ id, name }) => (
              <li key={id}>{name}</li>
            ))}
          </ul>
        </div>
      )}
    </form>
  );

useCallback

A function-based component doesn’t have lifecycles and React calls the function for each new render, which means that for each re-render every hoisted object will be recreated. For instance, a new handleFormSubmit function is created every time. One of the issues is that it invalidates the tree because<form onSubmit={handleFormSubmit}> is different between renders (previoushandleFormSubmit ≠ next handleFormSubmit because () => {} !== () => {}).

That’s where useCallback comes into play. It caches the function and creates a new one only if a dependency changes. A dependency is a value that is created in the component but is outside the useCallback scope.

const fn = useCallback(() => {}, [dependencies]);

In the documentation, they recommend “every value referenced inside the callback should also appear in the dependencies array.” Although, you may omit dispatch (from useReducer),setState, and useRef container values from the dependencies because React guarantees them to be static. However, it doesn’t hurt to specify them. Note that If we pass an empty array for the dependencies, it will always return the same function.

I recommend you to use eslint-plugin-react-hooks to help you to know which values we need to include in the dependencies.

You should also check the article written by Kent C. Dodds about when to use useCallback since it also comes with a performance cost to use it over an inline callback. Spoiler: for referential equality and dependencies lists.

So, if we follow how it was done with the class, we could execute the GETrequest directly in the useCallback.

const UserSearch = () => {
  const [loading, setLoading] = userState(false);
  const [users, setUsers] = useState();
  const [error, setError] = useState();

  const handleFormSubmit = useCallback(
    event => {
      event.preventDefault();

      setLoading(true);

      const request = superagent.get(
        `http://localhost:8080/users/${event.target.elements.username.value}`
      );
      request
        .then(response => {
          setLoading(false);
          setUsers(response.body.items);
        })
        .catch(error => {
          setLoading(false);
          setError(error);
        });
    },
    [setLoading, setUsers, setError]
  );

  return (
    <form onSubmit={handleFormSubmit}>
      {error && <p>Error: {error.message}</p>}

      <input type="text" name="username" disabled={loading} />
      <button type="submit" disabled={loading}>
        Search
      </button>

      {loading && <p>Loading...</p>}

      {users && (
        <div>
          <h1>Result</h1>
          <ul>
            {users.map(({ id, name }) => (
              <li key={id}>{name}</li>
            ))}
          </ul>
        </div>
      )}
    </form>
  );
};

⚠️ It works, there are few issues by doing that. When React unmounts the component, nothing aborts the request the same way we did incomponentWillUnmount. Also, since the request is pending React keeps a reference to an unmounted component. So, it wastes browser resources for something the user will never interact with.

useEffect

useEffect brings the lifecycle to a function based component. It is the combination of componentDidMount, componentDidUpdate, andcomponentWillUnmount. The callback of useEffect is executed when a dependency is updated. So, the first time the component is rendered, useEffectwill be executed. In our case, we want to start the request when the search value is updated (on form submit). We will introduce a new state searchValuethat is updated in the handleFormSubmit handler and we will use that state as a dependency to the hook. Therefore when searchValue is updated theuseEffect hook will also be executed.

Finally, the useEffect callback must return a function that is used to clean up, for us this is where we will abort the request.

const UserSearch = () => {
  const [loading, setLoading] = userState(false);
  const [users, setUsers] = useState();
  const [error, setError] = useState();
  const [searchValue, setSearchValue] = useState();

  const handleFormSubmit = useCallback(
    event => {
      event.preventDefault();
      setSearchValue(event.target.elements.username.value);
    },
    [setSearchValue]
  );

  useEffect(() => {
    let request;

    if (searchValue) {
      setLoading(true);

      request = superagent.get(
        `http://localhost:8080/users/${event.target.elements.username.value}`
      );
      request
        .then(response => {
          setError(undefined);
          setLoading(false);
          setUsers(response.body.items);
        })
        .catch(error => {
          setLoading(false);
          setError(error);
        });
    }

    return () => {
      if (request) {
        request.abort();
      }
    };
  }, [searchValue, setLoading, setUsers, setError]);

  return (
    <form onSubmit={handleFormSubmit}>
      {error && <p>Error: {error.message}</p>}

      <input type="text" name="username" disabled={loading} />
      <button type="submit" disabled={loading}>
        Search
      </button>

      {loading && <p>Loading...</p>}

      {users && (
        <div>
          <h1>Result</h1>
          <ul>
            {users.map(({ id, name }) => (
              <li key={id}>{name}</li>
            ))}
          </ul>
        </div>
      )}
    </form>
  );
};

Dan Abramov has written an excellent blog post about useEffect hooks: a complete guide to useEffect.

useReducer

We have now a working version of our component using React Hooks 🎉. One thing we could improve is when we have to keep track of several states, such as in the request’s response we update three states. In our example, I think it’s fine to go with the current version. However, in the case we need to add more states,useReducer would be a better suit. That allows us to gather related states in the same area of our code and have one way to update the states.

useReducer expects a reducer function (that function takes an action and returns a new state) and the initial state. Similar to useState it returns a tuple that contains the state and the dispatch function that we use to dispatch actions.

const [state, dispatch] = useReducer(reducer, initialState);

const initialState = {
  loading: false,
  users: undefined,
  error: undefined,
  searchValue: undefined,
};

const SET_SEARCH_VALUE = 'SET_SEARCH_VALUE';
const FETCH_INIT = 'FETCH_INIT';
const FETCH_SUCCESS = 'FETCH_SUCCESS';
const ERROR = 'ERROR';

const reducer = (state, { type, payload }) => {
  switch (type) {
    case SET_SEARCH_VALUE:
      return {
        ...state,
        searchValue: payload,
      };

    case FETCH_INIT:
      return {
        ...state,
        error: undefined,
        loading: true,
      };

    case FETCH_SUCCESS:
      return {
        ...state,
        loading: false,
        error: undefined,
        result: payload,
      };

    case ERROR:
      return {
        ...state,
        loading: false,
        error: payload,
      };

    default:
      throw new Error(`Action type ${type} unknown`);
  }
};

const UserSearch = () => {
  const [state, dispatch] = useReducer(reducer, initialState);

  const handleFormSubmit = useCallback(
    event => {
      event.preventDefault();

      dispatch({
        type: SET_SEARCH_VALUE,
        payload: event.target.elements.username.value,
      });
    },
    [dispatch]
  );

  useEffect(() => {
    let request;

    if (state.searchValue) {
      // highlight-next-line
      dispatch({ type: FETCH_INIT });

      request = superagent.get(
        `http://localhost:8080/users/${state.searchValue}`
      );
      request
        .then(response => {
          // highlight-next-line
          dispatch({ type: FETCH_SUCCESS, payload: response.body.items });
        })
        .catch(error => {
          // highlight-next-line
          dispatch({ type: ERROR, payload: error });
        });
    }

    return () => {
      if (request) {
        request.abort();
      }
    };
  }, [state.searchValue, dispatch]);

  return (
    <form onSubmit={handleFormSubmit}>
      {state.error && <p>Error: {state.error.message}</p>}

      <input type="text" name="username" disabled={state.loading} />
      <button type="submit" disabled={state.loading}>
        Search
      </button>

      {state.loading && <p>Loading...</p>}

      {state.users && (
        <div>
          <h1>Result</h1>
          <ul>
            {state.users.map(({ id, name }) => (
              <li key={id}>{name}</li>
            ))}
          </ul>
        </div>
      )}
    </form>
  );
};

As mentioned before, the benefits are not directly apparent since we don’t have that many states to handle in our example. There is more boilerplate than the useState version, but all states related to calling the API are managed in the reducer function.

Writing a meaningful commit message

Antoine Lehurt — Fri, 16 Nov 2018 12:00:00 +0000

Photo by @kaitlynbaker on Unsplash

When working in a team of developers, it’s important to share what you attended to achieve with your code and why you did it that way. It can be done using clear variable names, comments, … but also via Git commit messages.

Commit messages are useful for:

Code review: it helps the reviewer to follow your chain of thoughts, understand what you solved in your PR.
git blame: it brings context to the line/block of code.
git log, git rebase, git revert or git bisect: it helps you to grasp what the changes are about without having to dig into each line of code contained in the commit.

The structure of a commit message

I follow the rules detailed in the famous article from Chris Beams. They are the most common I encountered at work or in open source projects.

I like to follow his methodology to write the subject line. When writing the message, I think about the following sentence:

If applied, this commit will [your subject line]

I strongly recommend you to read the full article How to Write a Git Commit Message, it has a lot of great insights and guidance.

When things don’t go according to plan

git commit -am “Bunch of stuff”

It’s a good practice to commit as often as possible, since it simplifies the work when writing the commit message, hence a cleaner Git history. But, sometimes things don’t go as planned and we do too many changes without committing. Hopefully, it is possible to stage and commit code lines separately using git add --path. You can read more about it inThe Git Add Patch Command article in which the author describes how to achieve it using the command line or in VSCode. I prefer to use a GUI to do that since I have a better overview at what I want to stage instead of going chunk by chunk using the CLI. It’s actually the only reason I open a GUI for Git.

git commit -am “Oops forgot a semicolon.”

For some reason^*, an error passed through the linter and had been committed. We realise later when the CI is failing, and the PR rejected that we’ve forgotten a semicolon. Bummer. Committing that alone won’t be any value to the reviewer, and we might have to redo the fix if we need to revert to a previous state. Luckily the PR is still open so that we can add the missing semicolon in the right commit.

If the error occurred in the last commit, we could write the fix, stage and commit using the --amend flag. That way the change is part of the previous commit, incognito.

git add -A
git commit --amend --no-edit
# Push the fix to the PR branch
git push origin --force-with-lease

You can read more aboutwhy you should use --force-with-lease instead of --force.

Otherwise, if the issue happened earlier in Git history, we need to go back in time using the powerful git rebase. First, we need to find where it happened and we have several options:

Check the history of the given line where the issue is, using git blame.
Check the log to read through the changes, using git log --oneline orgit log -p (or using your favourite GUI).
And if none of it worked, we can use git bisect.

In my experience, since it’s related to one of my commits, I can find it using the log.

We have now found the commit, we can use its SHA hash and rebase on it:

git rebase -i e39a40e39bc325cde31b71402a79afb7be7e31ef^

e38a... is the SHA hash
The ^ at the end of the SHA hash is to specify that we want to start the rebase from this commit. Without it, it will begin at the next commit.

Git opens a new window^** where we specify the commands to run for each commit. Here, we replace pick with edit (or e for short) on the first line:

edit e39a40e The commit we want to update
pick 84da00a Another commit message

# Rebase e39a40e..84da00a onto e39a40e (2 commands)
#
# Commands:
# p, pick <commit> = use commit
# r, reword <commit> = use commit, but edit the commit message
# e, edit <commit> = use commit, but stop for amending
# s, squash <commit> = use commit, but meld into previous commit
# f, fixup <commit> = like "squash", but discard this commit's log message
# x, exec <command> = run command (the rest of the line) using shell
# d, drop <commit> = remove commit

Save the file, and Git brings us back at the commit.

Now, all we have to do is to add the missing semicolon, stage the change, continue the rebase and finally push the change to the remote branch.

git add -A
git rebase --continue
git push origin --force-with-lease

* I heard you like to commit using -n? 👀

** it’s possible to configure Git to use your favourite editor.

VSCode as a Vim editor

Antoine Lehurt — Sat, 08 Sep 2018 12:00:00 +0000

Photo by @goshua13 on Unsplash

In 2013 I started to use Vim as my primary editor, the journey hasn’t been without frustration, but in general, I really enjoyed using it. It took me sometimes, but I found a setup that worked well for me from auto completion to code navigation. What I love the most is Vim motions, I would not trade that feature for something else.

So, if everything was fine why did you start using VSCode?

I got mainly interested by VSCode for its debugging and refactoring features. I got used to debugging JavaScript or CSS in the browser’s dev tools, but I never found the right spot for debugging Node apps. With VSCode it is possible to debug directly in the editor, to add breakpoints or investigate the stack trace.

But, as usual, the first thing I do when I start to use a new code editor to install the Vim plugin.

VSCode Vim plugin

In a nutshell, VSCodeVim is really good. It is by far the best Vim integration I have tried outside Vim (or NeoVim) itself. It’s fast, includes plugins I love (easymotion, sneak, surround), and supports all motions and most shortcuts I used to use.

To get there I had to tweak the settings to be able to remap commands, but the great thing with this plugin is that we can remap loads of it!

For instance, I use jk to switch between insert and normal mode.

{
  "vim.insertModeKeyBindings": [
    {
      "before": ["j", "k"],
      "after": ["<Esc>"]
    }
  ]
}

You need to define that in User Settings. (Search forPreferences: Open User Settings. in the command palette (⇧⌘P).)

It is pretty straightforward, you define what mapping you want to use inbefore and what output you want to get into after.

I rely a lot on EasyMotion to move around (jump to a different line or a character) but I found the default setting quite annoying: I have a double press the leader key, instead of once in Vim, and then the action (for instance j to go to a line below). But, it is possible to remap it!

{
  "vim.normalModeKeyBindingsNonRecursive": [
    {
      "before": ["<leader>", "j"],
      "after": ["<leader>", "<leader>", "j"]
    }
  ]
}

You can remap not only key bindings but also execute commands. For instance to toggle a bookmark using ma:

{
  "vim.normalModeKeyBindingsNonRecursive": [
    {
      "before": ["m", "a"],
      "after": [],
      "commands": [
        {
          "command": "bookmarks.toggle",
          "args": []
        }
      ]
    }
  ]
}

I have been able to remap bindings to match my Vim memory muscles. I felt at home when starting to use VSCode.

You can find my VSCodeVim settings on this Gist.

Refactoring

VSCode has made some refactoring tasks easier than what I used to in Vim. One of my favourites is renaming a variable by pressing f2. All occurence will be updated in the project. The same happens when you rename a file or move it to another folder, its path is updated where it is used.

We can also transform arrow function with implicit return using cmd+.:

const add = (a, b) => a + b;

Put the curson on (, then press cmd+. ->add braces to arrow function. It will convert it to:

const add = (a, b) => {
  return a + b;
};

Super convenient when you need to debug a function.
It can also be used for disabling a ESLint rules for the current line.

In general, I find it more comfortable to refactor in VSCode, the multiple cursors works better than on Vim, and I can still use visual block mode when I need it.

Debugging

So far, I have only used the “attach to process” debug mode. When you run node (or nodemon) with the —inspect flag you can attach the process in VSCode to debug the application.

In launch.json

{
  "version": "0.2.0",
  "configurations": [
    {
      "type": "node",
      "request": "attach",
      "name": "dev:server inspect",
      "port": 5858,
      "restart": true,
      "protocol": "inspector"
    }
  ]
}

It’s an excellent way of debugging Node.js apps, so you don’t need to open a Chrome dev tools to add breakpoints and put debugger statement in your code.

Navigation

After some tuning, navigating in VSCode looks familiar to Vim:

Search a file using the fuzzy finder à la CtrlP.
Use the command palette to run commands when I don’t think it is necessary to memorise a key binding.
Jump between windows using ctrl + hjkl. (More about it in “What I miss from Vim” section.)
Go to definition using gf. (In Vim I used Ternjs to have this feature, “60% of the time, it works every time”.)
Use the code outline to jump between symbols in a file using cmd+shift+o. I’m in love with this feature.
Switch between tabs using gt (next tab) or gT (previous tab). ctrl + tab comes handy when I have too many files open, which happen more often to me because of the poor window management support on VSCode.
Jump to the next occurrence of the variable under the cursor using *.
Jump to the next changeusing <leader>n (next change) or <leader>p (previous change).
And of course, my beloved Vim motions.

Language support

The VSCode community is active, so I haven’t encountered a language that wasn’t supported: JavaScript (+JSX), TypeScript, Sass, Elm, Elixir/Phoenix, or Haskell.

Auto completion is right most of the time, except for CSS or Sass files where it struggles to suggest class names defined in a template file. It also has some issues to autocomplete snippets. If I type too fast, I will need to close and reopen the suggestion box to be able to run a snippet.

What I miss from Vim

Obviously, everything is not perfect. The main thing I miss from Vim is the window management, in VSCode the current support is really basic.

In Vim, it is possible to open several files under the same tab, so it is straight forward to create different spaces with related files and terminal open.For instance, you can open a tab containing all files related to a component.

| TAB A | TAB B
|       |-------------------------------------------------------------
Module.js     | Module.test.js     | Terminal that runs
              |                    | Module.test.js
              |--------------------|
              | Module.style.scss  |
              |                    |

In VSCode, tabs are all independent, so even if I can split the screen in two, I can’t switch tabs to change both files at the same time. So, I need to jump back and forth between the files to switch the tabs accordingly. Annoying.

| TAB Module.js | TAB Module.test.js | TAB Terminal
-------------------------------------------------------------------------

It creates some frustration when I try to jump quickly between files and terminals since I need to remember where are the related files are and keep things in sync manually.

What’s next?

I will keep using VSCode and haven’t planned to go back to my previous setup iTerm + NeoVim. It has (almost) everything I’m looking for: it is fast, it has good language, and auto completion support, a built-in terminal, and I can still use Vim in it. A nice thing is that most of my colleagues use it as well, so we can share settings in a project or do remote pair programming in VSCode directly, which is fantastic.