Update dependencies for mid March 2023 #678
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
And update Rails' dependencies.
loofah 2.19.0 --> 2.19.1 nokogiri 1.13.8 --> 1.14.2 racc 1.6.0 --> 1.6.2
rails-html-sanitizer 1.4.3 --> 1.5.0
globalid 1.0.0 --> 1.1.0 concurrent-ruby 1.1.10 --> 1.2.2 minitest 5.16.3 --> 5.18.0 tzinfo 2.0.5 --> 2.0.6 zeitwerk 2.6.1 --> 2.6.7
loader-utils 1.4.0 --> 1.4.2 loader-utils 2.0.0 --> 2.0.4
json5 1.0.1 --> 1.0.2 json5 2.1.3 --> 2.2.3
express 4.17.1 --> 4.18.2 accepts + 1.3.8 body-parser 1.19.0 --> 1.20.1 bytes 3.1.0 --> 3.1.2 content-disposition 0.5.3 --> 0.5.4 cookie 0.4.0 --> 0.5.0 depd + 2.0.0 destroy 1.0.4 --> 1.2.0 finalhandler 1.1.2 --> 1.2.0 forwarded 0.1.2 --> 0.2.0 http-errors 1.7.2 --> 2.0.0 http-errors - 1.7.3 mime-db + 1.52.0 mime-types + 2.1.35 ms 2.1.1 --> 2.1.3 negotiator + 0.6.3 on-finished 2.3.0 --> 2.4.1 proxy-addr 2.0.6 --> 2.0.7 qs 6.7.0 --> 6.11.0 raw-body 2.4.0 --> 2.5.1 send 0.17.1 --> 0.18.0 serve-static 1.14.1 --> 1.15.0 setprototypeof 1.1.1 --> 1.2.0 statuses + 2.0.1 toidentifier 1.0.0 --> 1.0.1
@braintree/sanitize-url 6.0.0 --> 6.0.2
fast-json-patch 3.1.0 --> 3.1.1
decode-uri-component 0.2.0 --> 0.2.2
DeeDeeG
force-pushed
the
update-dependencies-mid-March-2023
branch
from
1648eed to
e26d3e5
Compare
This sets the time docker-compose will wait for certain steps that happen to involve (internal) HTTP requests, but which may time out due to any other slowness on the machine, especially slow disk access. (docker-compose frequently times out for me unless I set this timeout variable properly to be much longer than the default of 60 s. So...) Set the timeout to be *much, much longer*, so it no-longer times out in any realistic situation. Makes development that much more pleasant for those contributing on slow hardware (especially those with spinning metal hard drives).
Results in a smaller final image on disk
This indirect dependency was updated exactly the same way in the latest webpack-dev-server's dependencies, so we don't have to manually resolve/override the dependency anymore in our package.json.
We can't use NodeJS 18 until we work through this issue: github[dot]com/webpack[slash]webpack/issues/14532 There was a default hashing algorithm for webpack (md4) that is now considered quite old/obsolete/flawed. It was removed from OpenSSL 3.0. OpenSSL 3.0 is the version of OpenSSL used in NodeJS 17 and up. In order to use an LTS version of Node that will receive long-term support over the next months, but not hit this issue where webpack errors out due to the md4 hash algorithm not being available in Node 17+, we need to stay on NodeJS 16.x for the time being. NOTE: NodeJS 16.x will be EOL on the 11th of September 2023, matching the EOL date for OpenSSL 1.1.1. See: https://nodejs.org/en/blog/announcements/nodejs16-eol/ https://github.com/nodejs/release#release-schedule So this workaround only buys us time until September of this year!! The "proper" fix for this would be updating to webpack 5 and webpacker 6.x (which was never given a final release, but got as far as a release candidate), or move to something that is actively supported, like the alternatives discussed here: https://world.hey.com/dhh/rails-7-will-have-three-great-answers-to-javascript-in-2021-8d68191b https://rubyonrails.org/2021/12/6/Rails-7-0-rc-1-released
Also update its direct and indirect dependencies.
This reverts commit 21c08d2.
Bumps indirect dependency ansi-html 0.0.7 to ansi-html-community 0.0.8
DeeDeeG
force-pushed
the
update-dependencies-mid-March-2023
branch
from
4c764e0 to
e87109f
Compare
|
Tests look good, local manual testing seems good, I'm merging this. |
DeeDeeG
added a commit
that referenced
this pull request
May 11, 2023
* Update dependencies for mid March 2023 (#678) - ruby: Upgrade from v3.1.2 to v3.2.1 - Gemfile[.lock]: Update Rails from 6.1.7 to 6.1.7.2 And update Rails' dependencies. - Gemfile.lock: Update loofah, nokogiri, and racc loofah 2.19.0 --> 2.19.1 nokogiri 1.13.8 --> 1.14.2 racc 1.6.0 --> 1.6.2 - Gemfile.lock: Update rails-html-sanitizer rails-html-sanitizer 1.4.3 --> 1.5.0 - Gemfile.lock: Update globalid and dependencies globalid 1.0.0 --> 1.1.0 concurrent-ruby 1.1.10 --> 1.2.2 minitest 5.16.3 --> 5.18.0 tzinfo 2.0.5 --> 2.0.6 zeitwerk 2.6.1 --> 2.6.7 - Gemfile.lock: Update rack from 2.2.4 to 2.2.6.3 - yarn.lock: Update loader-utils loader-utils 1.4.0 --> 1.4.2 loader-utils 2.0.0 --> 2.0.4 - yarn.lock: Update json5 json5 1.0.1 --> 1.0.2 json5 2.1.3 --> 2.2.3 - yarn.lock: Update qs 6.10.2 to 6.11.1 - yarn.lock: Update express and dependencies express 4.17.1 --> 4.18.2 accepts + 1.3.8 body-parser 1.19.0 --> 1.20.1 bytes 3.1.0 --> 3.1.2 content-disposition 0.5.3 --> 0.5.4 cookie 0.4.0 --> 0.5.0 depd + 2.0.0 destroy 1.0.4 --> 1.2.0 finalhandler 1.1.2 --> 1.2.0 forwarded 0.1.2 --> 0.2.0 http-errors 1.7.2 --> 2.0.0 http-errors - 1.7.3 mime-db + 1.52.0 mime-types + 2.1.35 ms 2.1.1 --> 2.1.3 negotiator + 0.6.3 on-finished 2.3.0 --> 2.4.1 proxy-addr 2.0.6 --> 2.0.7 qs 6.7.0 --> 6.11.0 raw-body 2.4.0 --> 2.5.1 send 0.17.1 --> 0.18.0 serve-static 1.14.1 --> 1.15.0 setprototypeof 1.1.1 --> 1.2.0 statuses + 2.0.1 toidentifier 1.0.0 --> 1.0.1 - yarn.lock: Update minimatch from 3.0.4 to 3.1.2 - yarn.lock: Update @braintree/sanitize-url @braintree/sanitize-url 6.0.0 --> 6.0.2 - yarn.lock: Update fast-json-patch fast-json-patch 3.1.0 --> 3.1.1 - yarn.lock: Update decode-uri-component decode-uri-component 0.2.0 --> 0.2.2 - Dockerfile: Check integrity of phantomjs - .env: Set COMPOSE_HTTP_TIMEOUT to 6 minutes This sets the time docker-compose will wait for certain steps that happen to involve (internal) HTTP requests, but which may time out due to any other slowness on the machine, especially slow disk access. (docker-compose frequently times out for me unless I set this timeout variable properly to be much longer than the default of 60 s. So...) Set the timeout to be *much, much longer*, so it no-longer times out in any realistic situation. Makes development that much more pleasant for those contributing on slow hardware (especially those with spinning metal hard drives). - yarn.lock: Dedupe some dependencies - yarn.lock: Dedupe mime-db package - Dockerfile: Delete yarn cache after install Results in a smaller final image on disk - Gemfile.lock: Update webpacker from 5.4.3 to 5.4.4 - webpacker: Run bundle exec rails webpacker:install - deps: Remove ansi-html-community resolution This indirect dependency was updated exactly the same way in the latest webpack-dev-server's dependencies, so we don't have to manually resolve/override the dependency anymore in our package.json. - yarn.lock: Dedupe babel and sub-dependencies - yarn.lock: Dedupe all other dependencies - package.json: Pin node to 16.x We can't use NodeJS 18 until we work through this issue: github[dot]com/webpack[slash]webpack/issues/14532 There was a default hashing algorithm for webpack (md4) that is now considered quite old/obsolete/flawed. It was removed from OpenSSL 3.0. OpenSSL 3.0 is the version of OpenSSL used in NodeJS 17 and up. In order to use an LTS version of Node that will receive long-term support over the next months, but not hit this issue where webpack errors out due to the md4 hash algorithm not being available in Node 17+, we need to stay on NodeJS 16.x for the time being. NOTE: NodeJS 16.x will be EOL on the 11th of September 2023, matching the EOL date for OpenSSL 1.1.1. See: https://nodejs.org/en/blog/announcements/nodejs16-eol/ https://github.com/nodejs/release#release-schedule So this workaround only buys us time until September of this year!! The "proper" fix for this would be updating to webpack 5 and webpacker 6.x (which was never given a final release, but got as far as a release candidate), or move to something that is actively supported, like the alternatives discussed here: https://world.hey.com/dhh/rails-7-will-have-three-great-answers-to-javascript-in-2021-8d68191b https://rubyonrails.org/2021/12/6/Rails-7-0-rc-1-released - Gemfile.lock: Update "rack" from 2.2.6.3 to 2.2.7 - Gemfile.lock: Update "nokogiri", 1.14.2 -> 1.14.3 - Gemfile[.lock]: Update "rails", 6.1.7.2 to 6.1.7.3 Also update its direct and indirect dependencies. - ruby: Upgrade from v3.2.1 to v3.2.2 - Revert "webpacker: Run bundle exec rails webpacker:install" This reverts commit 21c08d2. - yarn.lock: Update webpack-dev-server to 3.11.3 Bumps indirect dependency ansi-html 0.0.7 to ansi-html-community 0.0.8 * package.json: Pin Yarn to v1.x (fix Heroku) Yarn 3.x has an issue working with Heroku's nodejs buildpack. See: https://github[.]com/heroku[/]buildpacks-nodejs/issues/246 We are only intending to install this project with Yarn 1.x anyway. So, pin to Yarn v1.x. This change should allow the Heroku app to build successfully, and hopefully we will get a successful deployment to Heroku. --------- Co-authored-by: Mikena Wood <mi-wood@users.noreply.github.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Summary of Changes
Checklist