Illuminate components always expect the app to be the container, but also expect the app to be implementing the laravel app contract. This means that very often between minor illuminate updates we get a call to a method on the app that doesn't exist in the Flarum app. This fixes the issue once and for all.
* Do not catch exceptions when testing Console commands
This allows to easily test a case where a command should throw using `$this->expectException()`.
* Rewrite ConsoleTest to use expectException
Now that the ConsoleApplication is set to not catch exceptions.
---------
Co-authored-by: IanM <16573496+imorland@users.noreply.github.com>
* Make it possible to extend Flarum\Testing\integration\Setup\SetupScript and added public methods to add settings or extensions to in initial installation pipeline
* Fix syntax error, unexpected 'static'
* Remove `addExtensions` method and document `addSettings`
* test: password tokens are generated and deleted on password change
* chore: delete all password tokens when the password is changed
* test: email tokens are generated and deleted on email change
* test: email tokens are deleted after password reset
* chore: delete email tokens after password change
* test: password tokens are deleted after email change
* chore: delete password tokens after email change
* chore: syntactic sugar
* chore: unify event listening
With all the commits below, we resolve all outstanding typing issues in the repo, and CI jobs run green.
* fix: Convert DashboardPage and DashboardWidget to TypeScript
* fix: fix type errors in package manager ext
* fix: Convert Post component to TypeScript
* fix: avatar typings should accept null user
* fix: convert Notification component to TypeScript
* fix: properly use `typeof` in ForumApplication
* feat: make Notification content attr generic
* chore: format Notification component
* fix: Convert DiscussionRenamedNotification to TypeScript
* fix(pusher) move shims to a location where they get applied
* fix(pusher): fix some typing errors
* fix(akismet): fix some typing issues
* chore: update core dist typings
* chore(pusher): format
* fix: anchorScroll should accept string selectors
* fix: more accurately represent ApiQueryParamsPlural
* fix: convert PostStreamState to TypeScript
* chore(core): rebuild typings
* feat: allow extending app.routes
* fix: more flexible typings for highlight.ts
* fix: use primitive `number` type for Discussion typings
* fix: convert DiscussionListItem to TypeScript
* chore: rebuild core typings
* fix: final pusher type fixes
* feat: start tags TypeScript conversion
* fix: require-dev tags in pusher for CI TypeScript purposes.
* chore(core): format
* chore(tags): build dist typings
* feat(pusher): use dist types from tags.
* feat: convert flags to TypeScript
* chore(flags): generate dist typings
* fix(akismet): last type errors
* chore: update .yarn-integrity
* chore: partially run flarum-cli audit infra --fix
The tsconfig changes from that command are ignored, since we don't yet support "replacable sections" that would let us add custom config.
* chore: use type imports
* fix: broader gitattributes
* chore: run flarum-cli audit infra --monorepo --fix
* feat: make `app.data` typings extensible
* chore(core): format
* chore: boost tags TypeScript coverage
* fix(tags): further increase type coverage.
In normal Flarum, extensions are only enabled during requests. Here, however, we enable some during boot. This resolves the FilesystemManager early, which resolves the Url Generator early. To fix this, we directly provide a filesystem disk for assets instead of getting it from the filesystem manager.
This ensures a clean state for the extension currently being tested. The alternative requires the user to create and keep track of multiple test databases, or manually delete/re-recreate the database every time they switch between extensions being tested. Now, a simple `composer test:setup` will always reset the test environment to the original state.
Since we're making changes for the dev version of core, we should test against that too.
For now, this fixes issues with the `extensions` method of `Installation` being undefined.
This allows adding settings before the app is booted. In the past we've used hacky workarounds like manually resetting a binding to override singletons to use custom setting values. It makes sense to support this through `TestCase`.
It's not causing any issue because the correct variable name is always used to set and read the value, and PHP is fine setting new attributes on a class dynamically. It's just the explicit variables declared don't match with those actually used later.
Core's ExtensionManager only looks for extensions in the vendor directory, which makes sense for a Flarum instance, but is problematic if used in the context of a test suite for an extension. This PR:
- Adds a class extending ExtensionManager to include the current package
- Adds an extender that replaces ExtensionManager with this new class in container bindings
Effectively, this package can now be used to test extensions.
