DeeDeeG
commented
1 year ago Commit message when merging should be (click to expand):
``` * 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 21c08d2612441c32db6d6cb01f0ce20b656063bd. - 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 WoodEDIT: Updated to include the "pin Yarn to 1.x" hotfix specifically for deploying to Heroku (2c70ab90249274eab8ee80366b3deb693eeb8907).
Changelog
DeeDeeG (2): Update dependencies for mid March 2023 (#678) package.json: Pin Yarn to v1.x (fix Heroku) (https://github.com/RefugeRestrooms/refugerestrooms/pull/680/commits/2c70ab90249274eab8ee80366b3deb693eeb8907) (co-credit to @mi-wood for troubleshooting this issue)
mi-wood (1): package.json: Pin Yarn to v1.x (fix Heroku) (https://github.com/RefugeRestrooms/refugerestrooms/pull/680/commits/2c70ab90249274eab8ee80366b3deb693eeb8907) (co-credit to @DeeDeeG for implementing the small workaround to address this issue)
Checklist