BREAKING CHANGES:
- New versioning system: Allowing any amount of number segments, with prerelease support.
- Any number of segments is supported: 1, 1.0, 1.0.0, 1.0.0.0, ...
- Prerelease labels are compared "digit-run", similar to Debian.
- Plugins must specify a version.
- User-facing plugins should use CalVer. API plugins should use SemVer.
Revenge APIs use SemVer while the new `discord` dependency parses the Discord version string directly.
- Dependency is now a Map, with support for version ranges and optional. Suggested URL is removed. (See new repo system)
- Plugins will now have to declare a dependency on `revenge.api` (Revenge API version) and `discord` (Discord version).
- Manifest now requires a format version (currently `1`)
New APIs:
- lib/plugins/utils: Utilities to format versioning
Features:
- New repo system: Repository design is inspired by Linux package repositories.
- Repos host manifest, versions, channels, download URL/size, and hash for multiple plugins.
- New dependency system: Plugins are versioned, and shouldn't break when updates come.
Plugins can now declare dependency on supported Discord/Revenge API versions, so they won't break with auto-updates.
Dependencies can be optional, but dependency on `revenge.api` and `discord` must be required.
Dependents are soft-disabled when dependencies don't satisfy. Once satisfied, the plugin can start again.
- All updates for running plugins REQUIRE a reload to prevent stale linking issues. Both native and JS-side.
- Update checking is handled entirely by JS. But the native-side still handles installation, indexing, and verification.
- Local indexes are updated against remote indexes. Dependency checking always uses local indexes.
- Users can add custom repositories and custom their priority order. URL is the identity.
- Plugins can now have custom data URI icons instead of being restricted to React Native app assets.
- External plugin installs require UI confirmation before installing.
- Pending Update and Pending Reload filters in Plugins page.
- Ability to browse external plugins in repositories. Official repository will be added soon.
Fixes/Refactor:
- Refactored Plugin-related settings to a separate "Plugin Settings" plugin.
- Masonry layout fixes in landscape.
- Updated plugins now show "reload to apply" toast instead.
- Removed dead code.
BREAKING CHANGES:
- lib/modules!: Renamed `callBridgeMethod*` to `callNativeMethod*` and interface `Methods` to `NativeMethods`. This is to achieve naming consistency with the native API and be more clear.
- lib/storage!: Renamed to `@revenge-mod/json-storage`. A storage can be in any arbitrary format. While there's little potential for non-JSON storage formats, but the naming should allow for it regardless. This is not a drop-in replacements. There are breaking changes in export names and new APIs.
- plugins/revenge.api.storage!: Renamed to `revenge.api.jsonStorage`. Plugin options are renamed and its structure has changed as well.
- Native now holds the path for official storage APIs. This update uses new paths without any migration!
- lib/plugins!: `Plugin.errors` is now read-only. Use `Plugin.reportError(e)` instead.
- lib/plugins!: `Plugin.flags` has been completely removed in favor of these methods: `Plugin.requireReload()`, `Plugin.disable()`.
OTHER CHANGES:
- Fixed sorting for 'Enabled first'
- Updated native method names to be more consistent
- Cleand up dead code
- Make methods more 'safe' by removing non-null assertion casts
- Renamed `byX` filters to `withX`.
It is more correct. For example: You don't lookup, wait for, or get modules **BY** props. You lookup, wait for, and get modules **WITH** props.
- Renamed `*byImportedPath` to `*withImportedPath`
For consistency with the above change.
- Renamed `getModule` to `getModules`.
The API allows getting multiple modules and not just a single one. Types are renamed as well.
`getModuleByImportedPath` remains the same as it only gets one single module with a unique imported path.
- `withX` filter **helpers** removed.
They can now be replaced with the new capability-based `and` filter.
- `preferExports` and `moduleStateAware` filters removed.
They can now be replaced with the new capability-based `and` filter.
- Composite finders renamed.
`some` -> `or`, `every` -> `and`
- Composite finders takes a capability-based approach.
- Filter generators now need to attach runtime flag to let the system know whether the generated filter can be used to filter modules without proper exports or not.
## Misc.
- Removed useless unsub call in Profile Badges
- Use `queueMicrotask` with `asap`
# Features
## Capability-based approach to composite filters
```js
// Old
byProps(...).withDependencies(...)
// Old, same as: preferExports(byProps(...), byDependencies(...))
every(byDependencies(...), byProps(...))
// Old, ordering matters, this would fail unexpectedly!
every(byProps(...), byDependencies(...))
// New
withProps(...).and(withDependencies(...))
// New (as well), ordering doesn't matter, this has the same result as above
withDependencies(...).and(withProps(...))
```
