Our great sponsors
-
webpack
A bundler for javascript and friends. Packs many modules into a few bundled assets. Code Splitting allows for loading parts of the application on demand. Through "loaders", modules can be CommonJs, AMD, ES6 modules, CSS, Images, JSON, Coffeescript, LESS, ... and your custom stuff.
-
SurveyJS
Open-Source JSON Form Builder to Create Dynamic Forms Right in Your App. With SurveyJS form UI libraries, you can build and style forms in a fully-integrated drag & drop form builder, render them in your JS app, and store form submission data in any backend, inc. PHP, ASP.NET Core, and Node.js.
-
unimported
Discontinued Find and fix dangling files and unused dependencies in your JavaScript projects.
-
-
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
Run static analysis e.g. lint with lockfile-lint, Stylelint, ESLint, check for unimported files using unimported, and identify potential security vulnerabilities
Run webpack compilation to generate a browser-compatible bundle and emit bundle size metrics
Run static analysis e.g. lint with lockfile-lint, Stylelint, ESLint, check for unimported files using unimported, and identify potential security vulnerabilities
We first took a shot at addressing this gradually using a tool called Betterer, which works by taking a snapshot of the state of a set of errors, warnings, or undesired regular expressions in the codebase and surfacing changes in pull request diffs. Betterer had served us well in the past, such as when it helped us deprecate the Enzyme testing framework in favor of React testing library. However, because there were so many instances of noImplicitAny errors in the codebase, we found that much like snapshot tests, reviewers had begun to ignore Betterer results and we weren’t in fact getting better at all. Begrudgingly, we removed the rule from our Betterer tests and agreed to find a different way to enforce it. Luckily, this decision took place just in time for Snoosweek (Reddit’s internal hack week) so I was able to invest a few days into adding a new automation step to ensure incremental progress toward adherence to this rule.
Uses a library called parse-git-diff to construct a dictionary of changed files (and changed lines within each file for each file entry)
Run static analysis e.g. lint with lockfile-lint, Stylelint, ESLint, check for unimported files using unimported, and identify potential security vulnerabilities
As a general rule, my team prefers to automate code style and quality decisions whenever possible. This removes the need for an avalanche of repetitive comments about code style, allowing space for deeper discussions to take place in PRs as well as ensuring a uniform codebase. To this end, we make heavy use of ESLint rules and TypeScript configuration settings to surface issues both in the IDE (using plugins like Prettier), the command line (using pre-commit hooks to run linters and auto-fix auto-fixable issues), and in PRs (with help from the build pipeline). Here is where it gets tricky, though: when we identify new rules or config settings that we want to add, sometimes these cannot be automatically applied across the entire (very large) codebase. This is where custom scripts to enforce rules at file- or even line-level come into play – such as the one that powers this post’s titular bot.
Run static analysis e.g. lint with lockfile-lint, Stylelint, ESLint, check for unimported files using unimported, and identify potential security vulnerabilities