Fixed tpyo

Also added `.build` to gitignore cuz reasons

.gitignore

@@ -11,6 +11,7 @@ node_modules
 dist
 dist-ssr
 *.local
+build
 
 # Editor directories and files
 .vscode

biome.jsonc

@@ -1,7 +1,7 @@
 {
-  "$schema": "https://biomejs.dev/schemas/2.0.0/schema.json",
+  "$schema": "https://biomejs.dev/schemas/2.1.4/schema.json",
   "vcs": {
-    "enabled": false,
+    "enabled": true,
     "clientKind": "git",
     "useIgnoreFile": true,
     "defaultBranch": "beta"
@@ -20,12 +20,10 @@
     "includes": [
       "**",
       "!**/dist/**/*",
-      "!**/build/**/*",
       "!**/coverage/**/*",
       "!**/public/**/*",
       "!**/.github/**/*",
       "!**/node_modules/**/*",
-      "!**/.vscode/**/*",
       "!**/typedoc/**/*",
       // TODO: lint css and html?
       "!**/*.css",
@@ -67,11 +65,11 @@
         "noPrivateImports": "error"
       },
       "style": {
-        "useCollapsedIf": "warn", // TODO: promote to "error" eventually
+        "useCollapsedIf": "error",
         "noDoneCallback": "error",
         "noSubstr": "error",
-        "noYodaExpression": "warn", // TODO: Fix and promote to "error"
+        "noYodaExpression": "error",
-        "useForOf": "warn", // TODO: Fix and promote to "error"
+        "useForOf": "error",
         "useEnumInitializers": "off", // large enums like Moves/Species would make this cumbersome
         "useBlockStatements": {
           "level": "error",
@@ -88,7 +86,7 @@
           "level": "warn",
           "fix": "none"
         },
-        "useSingleVarDeclarator": "warn", // TODO: upgrade to "error"
+        "useSingleVarDeclarator": "error",
         "useNodejsImportProtocol": "off",
         "useTemplate": "off", // string concatenation is faster: https://stackoverflow.com/questions/29055518/are-es6-template-literals-faster-than-string-concatenation
         "useAsConstAssertion": "error",
@@ -139,11 +137,11 @@
       "performance": {
         "noNamespaceImport": "error",
         "noDelete": "error",
-        "noBarrelFile": "error",
+        "noBarrelFile": "error"
       },
       "nursery": {
         "useSingleJsDocAsterisk": "error",
-        // "useUnifiedTypeSignature": "error", TODO: upgrade to biome 2.1 and enable
+        "useUnifiedTypeSignature": "error",
         "useAdjacentGetterSetter": "error",
         "noConstantBinaryExpression": "error",
         "noTsIgnore": "error",

docs/linting.md

@@ -1,48 +1,58 @@
 # Linting & Formatting
 
-Writing clean, readable code is important, and linters and formatters are an integral part of ensuring code quality and readability.
+Writing clean, readable code is important, and linters and formatters are an integral part of ensuring code quality and readability. \
 It is for this reason we are using [Biome](https://biomejs.dev), an opinionated linter/formatter (akin to Prettier) with a heavy focus on speed and performance.
 
 ### Installation
-You probably installed Biome already without noticing it - it's included inside `package.json` and should've been downloaded when you ran `pnpm install` after cloning the repo. If you haven't done that yet, go do it.
+You probably installed Biome already without noticing it - it's included inside `package.json` and should've been downloaded when you ran `pnpm install` after cloning the repo. If you haven't done that yet, go do that first.
 
 # Using Biome
 
-For the most part, Biome attempts to stay "out of your hair", letting you write code while enforcing a consistent formatting standard and only notifying for errors it can't automatically fix.\
+For the most part, Biome attempts to stay "out of your hair", letting you write code while enforcing a consistent formatting standard and only notifying for errors it can't automatically fix. \
 On the other hand, if Biome complains about a piece of code, **there's probably a good reason why**. Disable comments should be used sparingly or when readabilty demands it - your first instinct should be to fix the code in question, not disable the rule.
 
 ## Editor Integration
 Biome has integration with many popular code editors. See [these](https://biomejs.dev/guides/editors/first-party-extensions/) [pages](https://biomejs.dev/guides/editors/third-party-extensions/) for information about enabling Biome in your editor of choice.
 
 ## Automated Runs
-Generally speaking, most users shouldn't need to run Biome directly; in addition to editor integration, [pre-commit hook](../lefthook.yml) will periodically run Biome before each commit.
+Generally speaking, most users shouldn't need to run Biome directly; in addition to editor integration, a [pre-commit hook](../lefthook.yml) will periodically run Biome before each commit on any changed files.
-You will **not** be able to push code with `error`-level linting problems - fix them beforehand.
 
-We also have a [Github Action](../.github/workflows/quality.yml) to verify code quality each time a PR is updated, preventing bad code from inadvertently making its way upstream.
+> ![WARNING]
+> You will **not** be able to commit code if any staged files contain `error`-level linting problems. \
+> If you, for whatever reason, _absolutely need_ to bypass Lefthook while committing,
+> `LEFTHOOK=0 git commit` will skip all pre-commit hooks for the given operation.
+
+We also have a [Github Action](../.github/workflows/quality.yml) to verify code quality each time a PR is updated, preventing bad code from inadvertently making its way upstream. \
+These are effectively the same commands as run by Lefthook, merely on a project-wide scale.
 
 ## Running Biome via CLI
-If you want Biome to check your files manually, you can run it from the command line like so:
+If you want Biome to check your files manually, you have 2 options:
+1. Run the `biome` script included in `package.json` (`pnpm biome`).
 
-```sh
+    This has sensible defaults for command-line options, but does not allow altering certain flags (as some cannot be specified twice in the same command)
-pnpm exec biome check --[flags]
+
-```
+2. Execute the Biome executable manually from the command line like so:
+    ```sh
+    pnpm exec biome check --[flags]
+    ```
+    This allows customizing flags non-overridable flags like `--diagnostic-level` on a more granular level, but requires slightly more verbosity.
 
 A full list of flags and options can be found on [their website](https://biomejs.dev/reference/cli/), but here's a few useful ones to keep in mind:
 
-- `--write` will cause Biome to write all "safe" fixes and formatting changes directly to your files (rather than just complaining and doing nothing).
+- `--write` will cause Biome to write all "safe" fixes and formatting changes directly to your files (rather than just complaining and erroring out).
-- `--changed` and `--staged` will only perform checks on all changed or staged files respectively. Biome sources this info from the relevant version control system (in this case Git).
+- `--changed` and `--staged` will limit checking to all changed or staged files respectively. Biome sources this info from the relevant version control system (in this case `git`).
 - `diagnostic-level=XXX` will only show diagnostics with at least the given severity level (`info/warn/error`). Useful to only focus on errors causing a failed workflow run or similar.
 
 ## Linting Rules
 
-We primarily use Biome's [recommended ruleset](https://biomejs.dev/linter/rules/) for linting JS/TS, with some customizations to better suit our project's needs[^1].
+We primarily use Biome's [recommended ruleset](https://biomejs.dev/linter/rules/) for linting JS/TS files, with some customizations to better suit our project's needs[^1].
 
 Some things to consider:
 
 - We have disabled rules that prioritize style over performance, such as `useTemplate`.
-- Some rules are currently disabled or marked as warnings (`warn`) to allow for gradual refactoring without blocking development. **Do not write new code that triggers these warnings.**
+- Some rules are currently marked as warnings (`warn`) to allow for gradual refactoring without blocking development. **Do not write new code that triggers these rules!**
 - The linter is configured to ignore specific files and folders (such as excessively large files or ones in need of refactoring) to improve performance and focus on actionable areas.
 
-Any questions about linting rules should be brought up in the `#dev-corner` channel in the discord.
+Any questions about linting rules can be brought up in the `#dev-corner` channel in the communityDiscord.
 
-[^1]: A complete list of rules can be found in the `biome.jsonc` file in the project root.
+[^1]: A complete list of rules can be found in the [`biome.jsonc`](../biome.jsonc) file in the project root. Many rules are accompanied by comments explaining the reasons for their inclusion (or lack thereof).

docs/localization.md

@@ -1,6 +1,6 @@
 # Localization 101
 
-PokéRogue's localization team puts immense effort into making the game accessible around the world, supporting over 12 different languages at the time of writing this document.  
+PokéRogue's localization team puts immense effort into making the game accessible around the world, supporting over 12 different languages at the time of writing this document.
 As a developer, it's important to help maintain global accessibility by effectively coordinating with the Translation Team on any new features or enhancements.
 
 This document aims to cover everything you need to know to help keep the integration process for localization smooth and simple.
@@ -19,11 +19,12 @@ This repository is integrated into the main one as a [git submodule](https://git
 
 ## What Is a Submodule?
 
-In essence, a submodule is a way for one repository (i.e. `pokerogue`) to use another repository (i.e. `pokerogue-locales`) internally. 
+In essence, a submodule is a way for one repository (i.e. `pokerogue`) to use another repository (i.e. `pokerogue-locales`) internally.
 The parent repo (the "superproject") houses a cloned version of the 2nd repository (the "submodule") inside it, making locales effectively a "repository within a repository", so to speak.
 
 >[!TIP]
 > Many popular IDEs have integrated `git` support with special handling around submodules:
+>
 > ![Image showing Visual Studio Code's `git` integration in the File Explorer. A blue "S" in the top right hand corner indicates the `public/locales` folder is a submodule.](https://github.com/user-attachments/assets/bd42d354-c65b-4cbe-8873-23d760dc1714 "What the `public/locales` submodule looks like in VS Code's File Explorer")
 >
 > ![Image showing Visual Studio Code's Source Control tab. A separate dropdown can be seen for each individual submodule.](https://github.com/user-attachments/assets/8b4d3f64-aec1-4474-91df-03dc1252a2fa "Making commits on submodules without even changing directories!")
@@ -32,14 +33,14 @@ The parent repo (the "superproject") houses a cloned version of the 2nd reposito
 
 The following command will initialize your branch's locales repository and update its HEAD:
 ```bash
-git submodule update --init --recursive
+pnpm update:locales
 ```
 
 > [!TIP]
 > This command is run _automatically_ after cloning, merging or changing branches, so you should rarely have to run it manually.
 
 > [!IMPORTANT]
-> If you run into issues with the `locales` submodule, try deleting the `.git/modules/public` and `public/locales` folders before re-running the command.
+> If you EVER run into issues with the `locales` submodule, try deleting the `.git/modules/public` and `public/locales` folders before re-initializing the repository.
 
 ## How Are Translations Integrated?
 
@@ -65,7 +66,7 @@ The basic process for fetching translated text goes roughly as follows:
     ```
 
 # Submitting Locales Changes
-If you have a feature or enhancement that requires additions or changes to in-game text, you will need to make a fork of the `pokerogue-locales` repo and submit your text changes as a pull request _in addition_ to your pull request to the main project.  
+If you have a feature or enhancement that requires additions or changes to in-game text, you will need to make a fork of the `pokerogue-locales` repo and submit your text changes as a pull request _in addition_ to your pull request to the main project. \
 Since these two PRs aren't _technically_ linked, it's important to coordinate with the Translation Team to ensure that both PRs are integrated safely into the project.
 
 > [!CAUTION]
@@ -73,25 +74,25 @@ Since these two PRs aren't _technically_ linked, it's important to coordinate wi
 
 ## Making Changes
 
-One perk of submodules is you don't actually _need_ to clone the locales repository to start contributing - initializing the submodule already does that for you.
+One perk of submodules is you don't actually _need_ to clone the locales repository to start contributing - `git` already does that for you on initialization.
 
 Given `pokerogue-locales` is a full-fledged `git` repository _inside_ `pokerogue`, making changes is roughly the same as normal, merely using `public/locales` as your root directory.
 
 > [!WARNING]
-> Make sure to checkout or rebase onto `upstream/HEAD` **BEFORE** creating a PR!
+> Make sure to checkout or rebase onto `upstream/main` (`pnpm update-locales:remote`) **BEFORE** creating a locales PR!
-> The checked-out commit is based on the superproject's SHA-1 by default, so hastily making changes may see you basing your commits on last week's `HEAD`.
+> The checked-out commit is based on the superproject's SHA-1 by default, so hastily making changes may see you basing your commits on last week 's `HEAD`.
 
 ## Requirements for Adding Translated Text
-When your new feature or enhancement requires adding a new locales key **without changing text in existing keys**, we require the following workflow with regards to localization:
+When a new feature or enhancement requires adding a new locales key **without changing text in existing keys**, we have the following workflow with regards to localization:
 1. You (the developer) make a pull request to the main repository for your new feature.
 If this feature requires new text, the text should be integrated into the code with a new `i18next` key pointing to where you plan to add it into the locales repository.
 2. You then make another pull request — this time to the `pokerogue-locales` repository — adding a new entry with text for each key you added to your main PR.
-  - You must add the corresponding **English keys** while making the PR; the Translation Team can take care of the rest[^2].
+    - You must add the corresponding **English keys** while making the PR; the Translation Team can take care of the rest[^2].
-  - For any feature pulled from the mainline Pokémon games (e.g. a Move or Ability implementation), it's best practice to include a source link for any added text.  
+    - For any feature pulled from the mainline Pokémon games (e.g. a Move or Ability implementation), it's best practice to include a source link for any added text. \
-  [Poké Corpus](https://abcboy101.github.io/poke-corpus/) is a great resource for finding text from the mainline games; otherwise, a video/picture showing the text being displayed should suffice.
+    [Poké Corpus](https://abcboy101.github.io/poke-corpus/) is a great resource for finding text from the mainline games; otherwise, a video/picture showing the text being displayed should suffice.
-  - You should also [notify the current Head of Translation](#notifying-translation) to ensure a fast response.
+    - You should also [notify the current Head of Translation](#notifying-translation) to ensure a fast response.
 3. At this point, you may begin [testing locales integration in your main PR](#documenting-locales-changes).
-4. The Translation Team will approve the locale PR (after corrections, if necessary), then merge it into `pokerogue-locales`.
+4. The Translation Team will approve the locales PR (after corrections, if necessary), then merge it into `pokerogue-locales`.
 5. The Dev Team will approve your main PR for your feature, then merge it into PokéRogue's beta environment.
 
 [^2]: For those wondering, the reason for choosing English specifically is due to it being the master language set in Pontoon (the program used by the Translation Team to perform locale updates).
@@ -102,7 +103,7 @@ If a key is present in any language _except_ the master language, it won't appea
 PRs that modify existing text have different risks with respect to coordination between development and translation, so their requirements are slightly different:
 - As above, you set up 2 PRs: one for the feature itself in the main repo, and another for the associated locales changes in the locale repo.
 - Now, however, you need to have your main PR be approved by the Dev Team **before** your corresponding locale changes are merged in.
-- After your main PR is approved, the Translation Team will merge your locale PR, and you may update the submodule and post video evidence of integration into the **locales PR**.
+- After your main PR is approved, you may update the submodule and post video evidence of integration into the **locales PR**.
 - A Lead or Senior Translator from the Translation Team will then approve your main PR (if all is well), clearing your feature for merging into `beta`.
 
 ## Documenting Locales Changes
@@ -111,12 +112,12 @@ After making a PR involving any outwards-facing behavior (but _especially_ local
 
 The basic procedure is roughly as follows:
 1. Update your locales submodule to point to **the branch you used to make the locales PR**. \
-   Many IDEs with `git` integration support doing this from the GUI, \
+    Many IDEs with `git` integration support doing this from the GUI, \
-   or you can simply do it via command-line:
+    or you can simply do it via command-line:
-   ```bash
+    ```bash
-   cd public/locales
+    cd public/locales
-   git checkout your-branch-name-here
+    git checkout your-branch-name-here
-   ```
+    ```
 2. Set some of the [in-game overrides](../CONTRIBUTING.md#1---manual-testing) inside `overrides.ts` to values corresponding to the interactions being tested.
 3. Start a local dev server (`pnpm start:dev`) and open localhost in your browser.
 4. Take screenshots or record a video of the locales changes being displayed in-game using the software of your choice[^2].
@@ -134,7 +135,7 @@ The easiest way to do this is by **pinging the current Head of Translation** in
 
 <!-- Remember to update this everytime the head of translation changes! -->
 > [!IMPORTANT]
-> The current Head of Translation is: \
+> The current Head of Translation is:
 > ** @lugiadrien **
 
 # Closing Remarks

lefthook.yml

@@ -1,10 +1,11 @@
 pre-commit:
-  skip: 
+  skip:
     - merge
     - rebase
   commands:
     biome-lint:
-      run: pnpm exec biome check --write --reporter=summary --staged --no-errors-on-unmatched
+      # Disable colors as certain IDEs don't allow it
+      run: pnpm exec biome check --write --colors="off" --staged --no-errors-on-unmatched
       stage_fixed: true
     ls-lint:
       run: pnpm exec ls-lint
@@ -12,11 +13,11 @@ pre-commit:
 post-merge:
   commands:
     update-submodules:
-      run: git submodule update --init --recursive
+      run: pnpm update-locales
 
 post-checkout:
   commands:
     update-submodules:
       # cf https://git-scm.com/docs/githooks#_post_checkout:
       # The 3rd argument is 1 for branch checkouts and 0 for file checkouts.
-      run: if test {3} -eq "1"; then git submodule update --init --recursive; fi
+      run: if test {3} -eq "1"; then pnpm update-locales; fi

package.json

@@ -24,10 +24,11 @@
     "postinstall": "lefthook install; git submodule update --init --recursive",
     "update-version:patch": "pnpm version patch --force --no-git-tag-version",
     "update-version:minor": "pnpm version minor --force --no-git-tag-version",
+    "update-locales": "git submodule update --progress --init --recursive",
     "update-locales:remote": "git submodule update --progress --init --recursive --force --remote"
   },
   "devDependencies": {
-    "@biomejs/biome": "2.0.0",
+    "@biomejs/biome": "2.1.4",
     "@ls-lint/ls-lint": "2.3.1",
     "@types/jsdom": "^21.1.7",
     "@types/node": "^22.16.5",

pnpm-lock.yaml

@@ -43,8 +43,8 @@ importers:
         version: 1.80.16(graphology-types@0.24.8)
     devDependencies:
       '@biomejs/biome':
-        specifier: 2.0.0
+        specifier: 2.1.4
-        version: 2.0.0
+        version: 2.1.4
       '@ls-lint/ls-lint':
         specifier: 2.3.1
         version: 2.3.1
@@ -180,55 +180,55 @@ packages:
     resolution: {integrity: sha512-ruv7Ae4J5dUYULmeXw1gmb7rYRz57OWCPM57pHojnLq/3Z1CK2lNSLTCVjxVk1F/TZHwOZZrOWi0ur95BbLxNQ==}
     engines: {node: '>=6.9.0'}
 
-  '@biomejs/biome@2.0.0':
+  '@biomejs/biome@2.1.4':
-    resolution: {integrity: sha512-BlUoXEOI/UQTDEj/pVfnkMo8SrZw3oOWBDrXYFT43V7HTkIUDkBRY53IC5Jx1QkZbaB+0ai1wJIfYwp9+qaJTQ==}
+    resolution: {integrity: sha512-QWlrqyxsU0FCebuMnkvBIkxvPqH89afiJzjMl+z67ybutse590jgeaFdDurE9XYtzpjRGTI1tlUZPGWmbKsElA==}
     engines: {node: '>=14.21.3'}
     hasBin: true
 
-  '@biomejs/cli-darwin-arm64@2.0.0':
+  '@biomejs/cli-darwin-arm64@2.1.4':
-    resolution: {integrity: sha512-QvqWYtFFhhxdf8jMAdJzXW+Frc7X8XsnHQLY+TBM1fnT1TfeV/v9vsFI5L2J7GH6qN1+QEEJ19jHibCY2Ypplw==}
+    resolution: {integrity: sha512-sCrNENE74I9MV090Wq/9Dg7EhPudx3+5OiSoQOkIe3DLPzFARuL1dOwCWhKCpA3I5RHmbrsbNSRfZwCabwd8Qg==}
     engines: {node: '>=14.21.3'}
     cpu: [arm64]
     os: [darwin]
 
-  '@biomejs/cli-darwin-x64@2.0.0':
+  '@biomejs/cli-darwin-x64@2.1.4':
-    resolution: {integrity: sha512-5JFhls1EfmuIH4QGFPlNpxJQFC6ic3X1ltcoLN+eSRRIPr6H/lUS1ttuD0Fj7rPgPhZqopK/jfH8UVj/1hIsQw==}
+    resolution: {integrity: sha512-gOEICJbTCy6iruBywBDcG4X5rHMbqCPs3clh3UQ+hRKlgvJTk4NHWQAyHOXvaLe+AxD1/TNX1jbZeffBJzcrOw==}
     engines: {node: '>=14.21.3'}
     cpu: [x64]
     os: [darwin]
 
-  '@biomejs/cli-linux-arm64-musl@2.0.0':
+  '@biomejs/cli-linux-arm64-musl@2.1.4':
-    resolution: {integrity: sha512-Bxsz8ki8+b3PytMnS5SgrGV+mbAWwIxI3ydChb/d1rURlJTMdxTTq5LTebUnlsUWAX6OvJuFeiVq9Gjn1YbCyA==}
+    resolution: {integrity: sha512-nYr7H0CyAJPaLupFE2cH16KZmRC5Z9PEftiA2vWxk+CsFkPZQ6dBRdcC6RuS+zJlPc/JOd8xw3uCCt9Pv41WvQ==}
     engines: {node: '>=14.21.3'}
     cpu: [arm64]
     os: [linux]
 
-  '@biomejs/cli-linux-arm64@2.0.0':
+  '@biomejs/cli-linux-arm64@2.1.4':
-    resolution: {integrity: sha512-BAH4QVi06TzAbVchXdJPsL0Z/P87jOfes15rI+p3EX9/EGTfIjaQ9lBVlHunxcmoptaA5y1Hdb9UYojIhmnjIw==}
+    resolution: {integrity: sha512-juhEkdkKR4nbUi5k/KRp1ocGPNWLgFRD4NrHZSveYrD6i98pyvuzmS9yFYgOZa5JhaVqo0HPnci0+YuzSwT2fw==}
     engines: {node: '>=14.21.3'}
     cpu: [arm64]
     os: [linux]
 
-  '@biomejs/cli-linux-x64-musl@2.0.0':
+  '@biomejs/cli-linux-x64-musl@2.1.4':
-    resolution: {integrity: sha512-tiQ0ABxMJb9I6GlfNp0ulrTiQSFacJRJO8245FFwE3ty3bfsfxlU/miblzDIi+qNrgGsLq5wIZcVYGp4c+HXZA==}
+    resolution: {integrity: sha512-lvwvb2SQQHctHUKvBKptR6PLFCM7JfRjpCCrDaTmvB7EeZ5/dQJPhTYBf36BE/B4CRWR2ZiBLRYhK7hhXBCZAg==}
     engines: {node: '>=14.21.3'}
     cpu: [x64]
     os: [linux]
 
-  '@biomejs/cli-linux-x64@2.0.0':
+  '@biomejs/cli-linux-x64@2.1.4':
-    resolution: {integrity: sha512-09PcOGYTtkopWRm6mZ/B6Mr6UHdkniUgIG/jLBv+2J8Z61ezRE+xQmpi3yNgUrFIAU4lPA9atg7mhvE/5Bo7Wg==}
+    resolution: {integrity: sha512-Eoy9ycbhpJVYuR+LskV9s3uyaIkp89+qqgqhGQsWnp/I02Uqg2fXFblHJOpGZR8AxdB9ADy87oFVxn9MpFKUrw==}
     engines: {node: '>=14.21.3'}
     cpu: [x64]
     os: [linux]
 
-  '@biomejs/cli-win32-arm64@2.0.0':
+  '@biomejs/cli-win32-arm64@2.1.4':
-    resolution: {integrity: sha512-vrTtuGu91xNTEQ5ZcMJBZuDlqr32DWU1r14UfePIGndF//s2WUAmer4FmgoPgruo76rprk37e8S2A2c0psXdxw==}
+    resolution: {integrity: sha512-3WRYte7orvyi6TRfIZkDN9Jzoogbv+gSvR+b9VOXUg1We1XrjBg6WljADeVEaKTvOcpVdH0a90TwyOQ6ue4fGw==}
     engines: {node: '>=14.21.3'}
     cpu: [arm64]
     os: [win32]
 
-  '@biomejs/cli-win32-x64@2.0.0':
+  '@biomejs/cli-win32-x64@2.1.4':
-    resolution: {integrity: sha512-2USVQ0hklNsph/KIR72ZdeptyXNnQ3JdzPn3NbjI4Sna34CnxeiYAaZcZzXPDl5PYNFBivV4xmvT3Z3rTmyDBg==}
+    resolution: {integrity: sha512-tBc+W7anBPSFXGAoQW+f/+svkpt8/uXfRwDzN1DvnatkRMt16KIYpEi/iw8u9GahJlFv98kgHcIrSsZHZTR0sw==}
     engines: {node: '>=14.21.3'}
     cpu: [x64]
     os: [win32]
@@ -2119,39 +2119,39 @@ snapshots:
       '@babel/helper-string-parser': 7.27.1
       '@babel/helper-validator-identifier': 7.27.1
 
-  '@biomejs/biome@2.0.0':
+  '@biomejs/biome@2.1.4':
     optionalDependencies:
-      '@biomejs/cli-darwin-arm64': 2.0.0
+      '@biomejs/cli-darwin-arm64': 2.1.4
-      '@biomejs/cli-darwin-x64': 2.0.0
+      '@biomejs/cli-darwin-x64': 2.1.4
-      '@biomejs/cli-linux-arm64': 2.0.0
+      '@biomejs/cli-linux-arm64': 2.1.4
-      '@biomejs/cli-linux-arm64-musl': 2.0.0
+      '@biomejs/cli-linux-arm64-musl': 2.1.4
-      '@biomejs/cli-linux-x64': 2.0.0
+      '@biomejs/cli-linux-x64': 2.1.4
-      '@biomejs/cli-linux-x64-musl': 2.0.0
+      '@biomejs/cli-linux-x64-musl': 2.1.4
-      '@biomejs/cli-win32-arm64': 2.0.0
+      '@biomejs/cli-win32-arm64': 2.1.4
-      '@biomejs/cli-win32-x64': 2.0.0
+      '@biomejs/cli-win32-x64': 2.1.4
 
-  '@biomejs/cli-darwin-arm64@2.0.0':
+  '@biomejs/cli-darwin-arm64@2.1.4':
     optional: true
 
-  '@biomejs/cli-darwin-x64@2.0.0':
+  '@biomejs/cli-darwin-x64@2.1.4':
     optional: true
 
-  '@biomejs/cli-linux-arm64-musl@2.0.0':
+  '@biomejs/cli-linux-arm64-musl@2.1.4':
     optional: true
 
-  '@biomejs/cli-linux-arm64@2.0.0':
+  '@biomejs/cli-linux-arm64@2.1.4':
     optional: true
 
-  '@biomejs/cli-linux-x64-musl@2.0.0':
+  '@biomejs/cli-linux-x64-musl@2.1.4':
     optional: true
 
-  '@biomejs/cli-linux-x64@2.0.0':
+  '@biomejs/cli-linux-x64@2.1.4':
     optional: true
 
-  '@biomejs/cli-win32-arm64@2.0.0':
+  '@biomejs/cli-win32-arm64@2.1.4':
     optional: true
 
-  '@biomejs/cli-win32-x64@2.0.0':
+  '@biomejs/cli-win32-x64@2.1.4':
     optional: true
 
   '@bundled-es-modules/cookie@2.0.1':

src/battle-scene.ts

@@ -1796,10 +1796,8 @@ export class BattleScene extends SceneBase {
     if (level >= 100) {
       ret++;
     }
-    if (species) {
+    if (species && species.baseTotal >= 670) {
-      if (species.baseTotal >= 670) {
+      ret++;
-        ret++;
-      }
     }
     ret += Math.floor(waveIndex / 250);
 
@@ -1843,12 +1841,7 @@ export class BattleScene extends SceneBase {
     this.rngCounter = 0;
   }
 
-  executeWithSeedOffset(
+  executeWithSeedOffset(func: () => void, offset: number, seedOverride?: string): void {
-    // biome-ignore lint/complexity/noBannedTypes: Refactor to not use Function
-    func: Function,
-    offset: number,
-    seedOverride?: string,
-  ): void {
     if (!func) {
       return;
     }