The date fields denoting creation and last update date are in fact
strings, not dates. IDK if it has always been this way or if e.g.
moving the online mod list from disk to IndexedDB changed this.

Luckily the date fields are only used for newer/older than comparisons,
and the ISO 8601 date strings yield the same results for those
operations as the Date objects would.

Online mod list was watching a wrong variable, and wouldn't fire an
autoupdate if the main mod list changed, i.e. if there was a background
update from Thunderstore API while user had the online mod list open.

This was broken some 6 months ago by yours truly while moving the mod
list into Vuex store.

Fix ThunderstoreMod date field typing

Fix watching online mod list for changes

GitHub actions dropped the support for MacOS 11, causing all CI jobs to
fail. Updating to MacOS 12 would require updating 3rd party
dependencies, namely electron-builder (see PR #1409).

MacOS isn't officially supported by this project, and it was added to
CI pipeline just because doing so was easy and only required a few
lines of config code. Now keeping MacOS on the CI pipeline would
require testing that updating electron-builder has no ill side-effects.
That work seems to have a low return of investment, so changes are it
won't get done anytime soon.

Add Hard Time III
Add Paquerette Down the Bunburrows
Add Shapez 2

Add 3 games

…mponent

Separate Zip extraction function from Profile Import Ui component

…component

Distance
FNAF Into The Pit
Tank Team

…arly return pattern consistently

Separate parseYamlToExportFormat function from ImportProfileModal UI …

…1385)

Additionally this avoids some internally inconsistent states, e.g. when the
game is changed but the mod list still contains mods for the old game.

---------

Co-authored-by: Antti Mäki <[email protected]>

…distance

Add 3 games

Update TankTeam cover image

Thunderstore API uses blob files to serve immutable data, as this can
be efficiently cached via CDN. The blobs contain stringified JSON that
is compressed with gzip to save storage space.

Fetching Lethal Company's package list containing 30k+ mods in one
request has been pushing the limits for a while now. For users with
slower connections the request timeouts, and the ICP message size limit
is soon starting to cause problems.

To address these problems, the package list is now downloaded in
chunks. Each chunk is a separate blob file that can be heavily cached
on CDN level. Chunks are downloaded serially to support slower
connections. Caching to IndexedDB is done only when all chunks have
been downloaded so transaction can used to make the operation atomic.

The hash identifies the last seen package list index, allowing us to
skip updating the database from file cache if there's no changes to
the package list.

The new table contains 0..1 rows for each game (because community
identifiers aren't available on the mod manager currently). Internal
game identifier acts as the primary key to prevent duplicates. Compound
index of game+hash is added for performance, and to silence "warnings"
that Dexie would otherwise log into the console.

Dexie's put method, i.e. upsert, is used to update the hash to the
database.

The hashes will be used to identify previously seen package list
indices. The Thunderstore API uses the same hash to identify blobs.
The hash is recalculated on the mod manager because:

- The API returns a redirect response, and we can't access the headers
  of the original response, only the result of redirect from the CDN
- The redirect can't be prevented and handled manually in the browser
  environment
- The response from the CDN does contain the hash as its used in the
  file name, but the only place Axios stores it in the response is a
  field that looks like it could easily change in the future versions

Since hashing the amount of data we're handling should be in a scale of
single digit milliseconds per chunk, this shouldn't be a problem.

While this makes some parts of the code (updating the progress text and
percentage shown on the UI) harder to follow, I feel this improves the
readability of the code overall. Especially when the upcoming additions
to the flow are taken into account.

In SplashMixin, skip downloading the chunks and updating them into the
IndexedDB if the index file indicates the packages haven't changed. If
downloading the index file itself fails, try to load earlier mod list
from the IndexedDB like it did earlier.

In UtilityMixin, skip the whole process if the index file indicates the
packages haven't changed, as at this point we already have the mod list
loaded in to Vuex. If loading the index file itself fails, the error is
caught by the caller, which handles retries as it did earlier.

Old approach used to read the timestamp from the package list table
since it wasn't available elsewhere. This approach no longer works
when we don't update the package list into database if it didn't
change. Instead, store the information in the same table as the
community's last seen index chunk hash. This timestamp is updated
whenever the same index hash is seen again, or when the hash changes
AND the new package list is successfully written to DB.

Old approach loaded the timestamp into Vuex when the package list was
read to Vuex state. With the new approach we need to take into account
that UtilityMixin skips updating the package list in memory if the list
didn't change. Instead, we need to update the timestamp manually.

While r2modman used Node's zlib as intended, TSMM used a library that
happened to be present as a 2nd degree dependency. While it worked, the
library had poor performance, taking ~3s to decompress each chunk,
while zlib and fflate takes next to no time at all.

Using DecompressionStream instead was considered, but based on a single
google result it seems that would require updating the TypeScript
version, which is a side quest for another time.

It was also considered sniffing the app version and using fflate only
on TSMM, so it wouldn't need to be added as a dependency on r2modman.
In the end gut feeling decided that would be unnecessarily complex and
prone to break due to future changes.

Thunderstore's main CDN regularly just fails to respond to requests.
Now that package list chunks are downloaded from the CDN, the issue
also affects this part of the program. While the only real fix is to
migrate to more reliable service provider, ETA on that is unknown.
Meanwhile do what can be done to mitigate the issue.

- Increase the number of retries and reduce the interval between them
  when loading the index chunk. Sometimes spamming the same request
  makes the CDN "wake up" and serve the file
- Add "preferred CDN" query parameter to index chunk request. If the
  Thunderstore API endpoint supports the received value, it will uses
  that CDN when returning the redirect response. Intercepting the
  redirect response to manipulate the redirect URL in the browser
  environment has proven hacky in the past and is avoided here
- Change the CDN on the fly on client when requesting the package list
  chunks. Since these request point directly to the CDN rather than
  Thunderstore API, manipulating them directly is feasible.

Separate installModAfterDownload function from UI component

Disable MacOS from CI pipeline

…ng profiles

ImportProfileModal improvements

…onent

Move readProfileFile function away from the UI component

Use new Thunderstore API to fetch community's package list

Skip unnecessary steps when package list hasn't changed

Use fflate to decompress package list chunks

Harden chunked package list API requests against CDN problems

The folder paths had been fixed earlier, but merging a long running dev
branch brought back the old, incorrect values.

Fix regression in Lethal Company/Content Warning data folder settings

TSMM can now override the methods locally without having to duplicate
the main implementation.

This is part of a larger refactoring effort aiming to remove the
business login from components so it can eventually be exported to be
a responsibility of a CLI tool.

Instead of inheritance, both classes only implement an interface
defining the common methods. This was done so that when a function
expects one of the classes, it won't accept the other. Being strict
about this makes it easier to see which part of the code base depend on
the active profile, and might reduce cases where passing wrong type of
object results in unexpected behaviour. The code duplication caused by
this within the classes seems like a small price to pay.

The static method for accessing the root dir of all profiles was
renamed to getRootDir() to make it clearer what directory it actually
returns. The method is not available on ImmutableProfile, since it
depends on the state of the app (active game) via PathResolver. We'll
likely add a non-static method to ImmutableProfile in a later commit
to reduce the dependency to app state where it's not required.

In retrospect IDK if this cleaned up the code as I thought it would.

These can be used to take an immutable snapshot of the currently active
profile.

Once starter, the outcome of mod linking operation shouldn't change if
the active profile is changed for whatever reason.

To prevent mega commit, call sites still use Profile for now.

This completes refactoring ProfileModList, which no longer relies on
the state tracking Profile object.

The method is not used anywhere, at least anymore.

The method isn't called from the outside and looks more like an
implementation detail for enableMod/disableMod methods.

applyModModeForSubdir creates FileTree objects internally and
applyModModeForState doesn't use FileTrees at all.

The location is always derived from the Profile object, which is passed
as an argument anyway. Furthermore, applyModModeForSubdir doesn't even
use the argument.

Ideally only ImmutableProfiles would be used, but settle for supporting
both Profiles and ImmutableProfiles for now to limit the scope of this
refactoring effort.

Now that the methods called by the actions which enable/disable mods
accept ImmutableProfiles as arguments, it makes sense for the actions
themselves to also use ImmutableProfiles.

This is a preparation step before GenericProfileInstaller.installMod
is changed to use ImmutableProfile as well.

GenericProfileInstaller.getInstallArgs will accept either profile
object for now to avoid needing to touch uninstall methods at this
time.

Avoid unnecessary non-null assertions as that's a bad habit. Throw an
error if components local state is invalid before starting the import.

This makes the code easier to read and might make it easier to refactor
the profileCreatedCallback further.

Profiles imported as code are always .r2z files. Previously user could
choose the older .r2x format when importing profile from a file, but
support for this was dropped recently, and only .r2z is supported now.

As a bonus this now handless the unlikely error properly instead of
just ignoring it silently.

This requires slight changes to addEventListener, but these changes are
probably an improvements by themselves.

- Earlier step has checked there's importable mods in the profile
- Download provider has another, less user-friendly check for the same
  thing to prevent the mod profile from getting stuck
- It doesn't seem anything catastrophic would happen even if the rest
  of the code is executed using an empty mod list

I don't see any reason for to wrap the code in the timeout. This might
have been relevant when the import step was started right away after a
new profile was created, by there now exists a preview window between
these steps so the folder should always exists. If it doesn't, the
100ms wait won't change things.

ThunderstoreDownloadProvider.downloadImportedMods:

- Drop completedCallback argument and return the comboList on success
  instead
- Rename callback argument to totalProgressCallback for clarity's sake
  and simplify it's signature. The other params are no longer needed
  since the errors aren't handled via the callback anymore

BetterThunderstoreDownloader

- Throw errors instead of reporting them via the callback system. While
  this is now inconsistent with other parts of the code base, the
  simplified error handling is deemed good enough reason to do so
  this simplifies the error handling on call site
- Define singleModProcessCallback internally. This also fixed an
  off-by-one (mod) in the progress percentage calculation, and doesn't
  mark a mod fully processed when it's downloaded, but only when it's
  also saved to disk
- The mods are now downloaded and saved using the internal helper
  methods instead of public downloadAndSave method which was previously
  called via public queueDownloadDependencies. The new functionality
  should be otherwise identical to downloadAndSave, except the steps
  can be awaited separately instead of relying on a callback to save
  the mod to disk

ImportProfileModal.vue

- Use the refactored downloadImportedProfileMods
- Expect errors to be thrown and handle them accordingly
- Drop downloadProgressCallback since a simple oneliner will do now
- Change downloadCompletedCallback to not use callbacks of its own

Some of the method names weren't very good to start with, and others
no longer fit the functionality after the recent refactoring.

- Don't handle errors here, let them flow to call site instead
- Reduce looping by gathering list of disabled mods separately

- Change the method to accept ImmutableProfile as a parameter to
  separate it from the UI component state
- Move the method to ProfileUtils as a standalone function
- Include installModAfterDownload functionality in installModsToProfile
  as the former is no longer needed

Use ImmutableProfile for installing the mods. Especially when updating
an existing profile this saves us from switching between the temporary
and target profiles.

Active profile is now only updated if the import process finishes
successfully.

Download provider will now handle only the downloading, as fitting its
moniker. Casting one type of object presenting a mod to another type
is done in a separate helper function. This will eventually reduce the
number of arguments passed around between different functions.

- Move parts of profileCreatedCallback to ProfileUtils
- Absorp the functionality from downloadAndSaveMods directly into
  profileCreatedCallback, as the method has been greatly reduced in
  size by previous refactoring, and the readability of the code no
  longer warrants this separation
- As far as I'm concerned, the refactoring of this particular method
  is now completed: all that remains in the method is reading and
  updating the state of the component and the app, and all business
  logic has been moved behind three external methods. While the three
  could be combined into one, it would IMO then become too big of a
  function
- Rename the method to importProfile, since it's not really a callback
  function

Initially progress was based purely on downloading the mods. It was
recently changed so that extracting the downloaded mod to cache is
allocated 20% of the progress of processing the mod in this step.

However, this still leaves users hanging on 100% completion while the
mods from the cache and configs from the imported profile zip are
copied to the profile folder. These steps now have their own progress
indicators.

Add new ImmutableProfile class that doesn't track the active profile

Refactor ModLinker to use ImmutableProfile

Refactor ProfileModList to use ImmutableProfile

…ider

Refactor download method of download provider to use ImmutableProfile

…llprovider-mode

Refactor ProfileInstallerProvider to use ImmutableProfile when enabling/disabling mods

…llprovider-install

Refactor ProfileInstallerProvider to use ImmutableProfile when installing mods

Continue refactoring ProfileImportModal to eventually separate business logic from UI