Dependency Updates: `devDependencies`, Renovate, etc.

[ChristopherChudzicki]

Description/Context

Many of our dependencies are significantly out of date. For example, we use postcss-import v12, whereas v16 is the latest; we use sass-loader v8, whereas v14 is the latest.

It would be nice to update dependencies automatically, e.g., with Renovate. However, may not want Renovate to auto-merge major version updates—even if tests pass—of things that make it into our production bundle, since major version updates could affect browser support.

Plan/Design

My thoughts are:

• First, group our package.json dependencies into devDependencies and dependencies. Things that make it into our production bundle (jquery, lodash, etc) would go in dependencies. Build and dev tools (webpack, eslint, etc) would be devDependencies.
• While doing the above, audit our dependencies. Some are unused (for example—as far as I can tell—walk is unused). Remove unused dependencies.
• Configure renovate to update stuff.
  • I would not recommend auto-merging major updates to dependencies.
  • We may not want to auto-merge updates to hugo-bin-extended.

[gumaerc]

Devil's advocate for auto-updating hugo-bin-extended:

The Node based Hugo package here is only used for local development. Having it auto update would mean that we would become more aware of issues with Hugo more quickly, rather than finding out about things when we go to update the version we use in production. Although, there's also something to be said about simply pinning to the version in production. That way, everything you test locally should behave the same in production.

[HussainTaj-arbisoft]

Renovate was configured for this repo in https://github.com/mitodl/ocw-hugo-themes/pull/1270. Minor dependencies are being updated and auto-merged. I believe hugo-bin-extended is in the queue to be auto-merged soon.

---

That way, everything you test locally should behave the same in production.

I believe this is the main motivation for disabling auto merges for hugo-bin-extended. If I were to develop something based on a newer feature of an auto-updated Hugo and it fails on RC, checking the Hugo version might not be my first instinct.

I can see the potential in the auto-updates. Perhaps when we have a more thorough suite of e2e tests, we can automate the version updates on both ends i.e. course publisher imag and npm package.

I've created https://github.com/mitodl/ocw-hugo-themes/pull/1357 which should prevent the renovate auto-merges for hugo-bin-extended once merged.