2023-10-25 15:16:46 -07:00
|
|
|
source 'https://rubygems.org'
|
2024-09-20 12:47:23 -07:00
|
|
|
ruby '3.3.5'
|
2010-05-14 15:12:31 -07:00
|
|
|
|
2024-09-20 12:57:55 -07:00
|
|
|
gem 'rails', '~> 7.2', '>= 7.2.1'
|
2023-08-02 13:36:28 -07:00
|
|
|
|
2023-08-03 16:15:23 -07:00
|
|
|
# The HTTP server running the Rails instance.
|
2024-09-07 12:14:12 -07:00
|
|
|
gem 'falcon', '~> 0.48.0'
|
2023-08-03 16:15:23 -07:00
|
|
|
|
2023-08-02 13:36:28 -07:00
|
|
|
# Our database is MySQL, in both development and production.
|
2023-08-02 16:05:02 -07:00
|
|
|
gem 'mysql2', '~> 0.5.5'
|
2010-10-10 15:46:58 -07:00
|
|
|
|
2023-08-02 13:36:28 -07:00
|
|
|
# For reading the .env file, which you can use in development to more easily
|
|
|
|
# set environment variables for secret data.
|
2023-08-02 13:41:37 -07:00
|
|
|
gem 'dotenv-rails', '~> 2.8', '>= 2.8.1'
|
2023-08-02 13:36:28 -07:00
|
|
|
|
|
|
|
# For the asset pipeline: templates, CSS, JS, etc.
|
2023-08-22 16:08:11 -07:00
|
|
|
gem 'sprockets', '~> 4.2'
|
2023-07-22 12:58:15 -07:00
|
|
|
gem 'haml', '~> 6.1', '>= 6.1.1'
|
2023-08-22 16:08:11 -07:00
|
|
|
gem 'sass-rails', '~> 6.0'
|
2023-08-19 18:51:46 -07:00
|
|
|
gem 'terser', '~> 1.1', '>= 1.1.17'
|
2023-08-02 13:36:28 -07:00
|
|
|
gem 'react-rails', '~> 2.7', '>= 2.7.1'
|
2024-10-21 16:03:58 -07:00
|
|
|
gem 'jsbundling-rails', '~> 1.3'
|
Add Turbo to speed up the app, and set up for missing UJS features
Oh right, we don't have Rails UJS going on anymore, which is what
handled the confirmation prompts for deleting lists. Turbo is the more
standard modern solution to that, and should speed up certain
pageloads, so let's do it!
Here I install the `turbo-rails` gem, then run `rails turbo:install` to
install the `@hotwired/turbo-rails` npm package. Then I move
`application.js` that's run all on pages but the outfit editor into our
section of JS that gets run through the bundler, and add Turbo to it.
I had to fix a couple tricky things:
1. The outfit editor page doesn't play nice with being swapped into the
document, so I make it require a full page reload instead.
2. Prefetching the Sign In link can cause the wrong `return_to` address
to be written to the `session`. (It's a GET request that does, ever
so slightly, take its own actions, oops!) As a simple hacky answer,
we disallow prefetching on that link.
Haven't fixed up the UJS stuff for confirm prompts to use Turbo yet,
that's next!
2024-03-13 13:43:48 -07:00
|
|
|
gem 'turbo-rails', '~> 2.0'
|
2023-08-02 13:36:28 -07:00
|
|
|
|
|
|
|
# For authentication.
|
2023-08-02 15:18:36 -07:00
|
|
|
gem 'devise', '~> 4.9', '>= 4.9.2'
|
2023-08-06 15:52:05 -07:00
|
|
|
gem 'devise-encryptable', '~> 0.2.0'
|
2024-03-13 13:10:59 -07:00
|
|
|
gem 'omniauth', '~> 2.1'
|
|
|
|
gem 'omniauth-rails_csrf_protection', '~> 1.0'
|
2024-03-14 18:11:40 -07:00
|
|
|
gem "omniauth_openid_connect", "~> 0.7.1"
|
2011-01-13 14:22:07 -08:00
|
|
|
|
2023-08-02 16:30:17 -07:00
|
|
|
# For pagination UI.
|
|
|
|
gem 'will_paginate', '~> 4.0'
|
|
|
|
|
2023-08-02 13:36:28 -07:00
|
|
|
# For translation, both for the site UI and for Neopets data.
|
2023-08-02 17:27:11 -07:00
|
|
|
gem 'rails-i18n', '~> 7.0', '>= 7.0.7'
|
2023-08-02 13:36:28 -07:00
|
|
|
gem 'http_accept_language', '~> 2.1', '>= 2.1.1'
|
2010-05-15 15:58:28 -07:00
|
|
|
|
2023-08-02 13:36:28 -07:00
|
|
|
# For reading and parsing HTML from Neopets.com, like importing Closet pages.
|
2023-08-03 16:43:37 -07:00
|
|
|
gem 'nokogiri', '~> 1.15', '>= 1.15.3'
|
2011-07-12 16:37:16 -07:00
|
|
|
|
2023-08-02 13:36:28 -07:00
|
|
|
# For safely rendering users' Markdown + HTML on item list pages.
|
2023-08-02 17:16:24 -07:00
|
|
|
gem 'rdiscount', '~> 2.2', '>= 2.2.7.1'
|
|
|
|
gem 'sanitize', '~> 6.0', '>= 6.0.2'
|
2011-07-29 07:52:04 -07:00
|
|
|
|
2023-08-02 13:36:28 -07:00
|
|
|
# For working with Neopets APIs.
|
|
|
|
# unstable version of RocketAMF interprets info registry as a hash instead of an array
|
|
|
|
gem 'RocketAMF', :git => 'https://github.com/rubyamf/rocketamf.git'
|
2012-05-21 09:48:19 -07:00
|
|
|
|
2023-08-02 13:36:28 -07:00
|
|
|
# For preventing too many modeling attempts.
|
2023-08-02 17:16:24 -07:00
|
|
|
gem 'rack-attack', '~> 6.7'
|
2013-07-02 14:10:01 -07:00
|
|
|
|
2023-08-02 13:36:28 -07:00
|
|
|
# For testing emails in development.
|
2023-08-02 17:16:24 -07:00
|
|
|
gem 'letter_opener', '~> 1.8', '>= 1.8.1', group: :development
|
2014-09-10 12:32:54 -07:00
|
|
|
|
2023-08-02 13:36:28 -07:00
|
|
|
# For parallel API calls.
|
2023-08-02 17:16:24 -07:00
|
|
|
gem 'parallel', '~> 1.23'
|
2013-03-05 18:08:57 -08:00
|
|
|
|
2023-10-25 15:05:31 -07:00
|
|
|
# For miscellaneous HTTP requests.
|
2024-08-27 17:06:22 -07:00
|
|
|
gem "httparty", "~> 0.22.0"
|
2023-11-03 16:20:02 -07:00
|
|
|
gem "addressable", "~> 2.8"
|
2023-10-25 15:05:31 -07:00
|
|
|
|
2023-11-10 16:52:50 -08:00
|
|
|
# For advanced batching of many HTTP requests.
|
2024-09-07 12:14:12 -07:00
|
|
|
gem "async", "~> 2.17", require: false
|
|
|
|
gem "async-http", "~> 0.75.0", require: false
|
2023-11-10 16:52:50 -08:00
|
|
|
gem "thread-local", "~> 1.1", require: false
|
|
|
|
|
2023-08-02 15:41:22 -07:00
|
|
|
# For debugging.
|
2023-08-02 17:36:32 -07:00
|
|
|
gem 'web-console', '~> 4.2', group: :development
|
2023-08-02 15:41:22 -07:00
|
|
|
|
2023-08-02 16:17:07 -07:00
|
|
|
# Reduces boot times through caching; required in config/boot.rb
|
2023-08-02 17:16:24 -07:00
|
|
|
gem 'bootsnap', '~> 1.16', require: false
|
2023-10-27 19:38:49 -07:00
|
|
|
|
|
|
|
# For investigating performance issues.
|
|
|
|
gem "rack-mini-profiler", "~> 3.1"
|
|
|
|
gem "memory_profiler", "~> 1.0"
|
|
|
|
gem "stackprof", "~> 0.2.25"
|
2023-11-06 12:37:40 -08:00
|
|
|
|
|
|
|
# For monitoring errors in production.
|
|
|
|
gem "sentry-ruby", "~> 5.12"
|
|
|
|
gem "sentry-rails", "~> 5.12"
|
2024-01-19 00:00:46 -08:00
|
|
|
|
Create `rails public_data:commit` task, to share public data dumps
I'm starting to port over the functionality that was previously just,
me running `yarn db:export:public-data` in `impress-2020` and
committing it to Git LFS every time.
My immediate motivation is that the `impress-2020` git repository is
getting weirdly large?? Idk how these 40MB files have blown up to a
solid 16GB of Git LFS data (we don't have THAT many!!!), but I guess
there's something about Git LFS's architecture and disk usage that I'm
not understanding.
So, let's move to a simpler system in which we don't bind the public
data to the codebase, but instead just regularly dump it in production
and make it available for download.
This change adds the `rails public_data:commit` task, which when run in
production will make the latest available at
`https://impress.openneo.net/public-data/latest.sql.gz`, and will also
store a running log of previous dumps, viewable at
`https://impress.openneo.net/public-data/`.
Things left to do:
1. Create a `rails public_data:pull` task, to download `latest.sql.gz`
and import it into the local development database.
2. Set up a cron job to dump this out regularly, idk maybe weekly? That
will grow, but not very fast (about 2GB per year), and we can add
logic to rotate out old ones if it starts to grow too far. (If we
wanted to get really intricate, we could do like, daily for the past
week, then weekly for the past 3 months, then monthly for the past
year, idk. There must be tools that do this!)
2024-02-29 14:30:33 -08:00
|
|
|
# For tasks that use shell commands.
|
|
|
|
gem "shell", "~> 0.8.1"
|
2024-07-01 15:35:39 -07:00
|
|
|
|
|
|
|
# For workspace autocomplete.
|
2024-11-19 11:28:36 -08:00
|
|
|
group :development do
|
|
|
|
gem "solargraph", "~> 0.50.0"
|
|
|
|
gem "solargraph-rails", "~> 1.1"
|
|
|
|
end
|
2024-10-21 16:03:58 -07:00
|
|
|
|
|
|
|
# For automated tests.
|
|
|
|
group :development, :test do
|
|
|
|
gem "rspec-rails", "~> 7.0"
|
2024-11-14 18:45:08 -08:00
|
|
|
gem "webmock", "~> 3.24", group: :test
|
2024-10-21 16:03:58 -07:00
|
|
|
end
|