eslint-config-groupon

ESLint configuration used by Groupon

Usage no npm install needed!

<script type="module">
  import eslintConfigGroupon from 'https://cdn.skypack.dev/eslint-config-groupon';
</script>

README

nlm-github nlm-node nlm-version

JavaScript at Groupon

This repository contains tools & guidelines for using JavaScript at Groupon. It represents the best effort to capture the current practices.

Writing NPM Packages

ES5 or ES2021?

For client-side code we depend on babel-preset-env to ensure that both application- and library code is compiled down to whatever our targeted browsers support.

Versioning and Publishing

We use nlm to manage our libraries. This ensures that:

  1. Every library has a usable CHANGELOG.md file as part of its git history.
  2. Releases are never tied to a single person.
  3. We can easily share best practices across projects.

Groupon JavaScript Style Guide

Fortunately there already is a great and well-documented style guide for JavaScript over at airbnb/javascript. It definitely is worth a read and in many ways we're staying fairly close to it.

There's some important differences that are mostly around our focus on sticking to features natively supported by Node where possible, and a higher bar for rules that don't support --fix: If a rule isn't clearly preventing bugs, it has to support --fix to be enabled.

Additionally, our file naming convention is kabab-case. File names should be entirely in lowercase to avoid any renaming issues with file systems.

Regarding code organization, we generally structure code by domain, not by layer (todos/model.js instead of models/todo.js).

To ensure good automation support, we're also dropping any rules that conflict with prettier's formatting.

The Longer Answer

We split our rules into three categories:

  • Mistakes: Things that should only appear because the developer made a mistake, 99% of the time. If these errors aren't fixed, we wouldn't expect the program to work correctly. This is the only category where we allow "error" even for rules that don't support --fix.
  • Conventions: Points out patterns that we believe could lead to confusion or maintenance issues down the line. If a rule isn't fixable, there should be a high bar for it to be enabled to not cause noise. Even if a rule is enabled, it may at most warn.
  • Opinions: Things that are arbitrary choices. Most whitespace and formatting rules fall into this category. Everything in here must support --fix and shouldn't require human intervention.

Groupon TypeScript Style Guide

You may have your .eslintrc extend groupon/typescript to get a set of configs based on our JavaScript lint configs, but with tweaks to work better with TypeScript (parsing, defaults, etc.).