The strategy I implemented in #348 to always update the browserslist-db on install and commit the results creates a lot of noise: a lot of similar commits, and we still want to update this db in deploy anyway, so it's not the right strategy.
This commit removes the code that commits the changes, and instead updates the db in every workflow that tests or deploys Studio-Web.
Furthermore, Del is going to add has added a build-time dependency that will do this update automatically when you build or serve locally, so we do the same everywhere, automatically, and reasonably quietly.
Fixes?
will reduce the number of silly nearly meaningless commits to package-lock.json.
Feedback sought?
Once Del implements the auto update on build, that will create local changes. Are we OK with just grabbing those with other commits we're doing locally? Or do we want to avoid committing those changes (that would be a real nuisance)?
PR Goal?
The strategy I implemented in #348 to always update the browserslist-db on install and commit the results creates a lot of noise: a lot of similar commits, and we still want to update this db in deploy anyway, so it's not the right strategy.
This commit removes the code that commits the changes, and instead updates the db in every workflow that tests or deploys Studio-Web.
Furthermore, Del
is going to addhas added a build-time dependency that will do this update automatically when you build or serve locally, so we do the same everywhere, automatically, and reasonably quietly.Fixes?
will reduce the number of silly nearly meaningless commits to
package-lock.json
.Feedback sought?
Once Del implements the auto update on build, that will create local changes. Are we OK with just grabbing those with other commits we're doing locally? Or do we want to avoid committing those changes (that would be a real nuisance)?
Priority?
low
Tests added?
n/a
How to test?
It's just CI, so look at CI results for this PR.
Confidence?
medium
Version change?
no