* Update core to use new Webpack and TSConfig
* Bump webpack dep
* Update JS build action
* Copy custom `.d.ts` files to `dist-typings` folder on typings compile
* Run workflow against action v2
This allows us to have a moving tag, like first party actions have.
* Remove bundle analyzer from core
* Use webpack config 0.1.0-beta.16.2
* Add note about checking flarum-tsconfig
This naming is clearer as to the intended effect. Changes include:
- A migration to rename all permissions
- Updating the seed migration to use the original naming from the start
- Replacing usage of the old names with new names in code
- Throwing warnings when the old names are used.
- Convert KeyboardNavigatable to TypeScript, as that is used internally here.
- Convert search sources to TypeScript
- Convert Search component to TypeScript
- Convert Search States to Typescript
- Add `getInitialSearch` to `SearchState`
- Fix search disappearing on page reload / direct link
Data migrations (seed default groups, seed default permissions) are deliberately excluded.
This also allows us to remove a lot of now unnecessary public API from the migrator and migration repository.
- Change index files to ts
- Remove deprecated EditUserModal from forum compat
- Remove b14-specific error
- Remove transChoice method (ICU should be used instead)
- Translator to TypeScript
- Small JS => TS cleanup
* Trivial js => ts change
Co-authored-by: David Wheatley <hi@davwheat.dev>
* Add Tooltip component to common
Will be used to provide backwards compatibility when we switch to CSS tooltips.
All other methods of creating tooltips are deprecated and this component-based method should be used instead.
* Modify direct child instead of using container element
Instead of using a container to house the tooltip, we'll now modify the
first direct child of the Tooltip component.
The Tooltip component will ensure that:
- children are passed to it
- only one child is present
- that child is an actual HTML Element and not a text node, or similar
- that child is currently present in the DOM
Only after all of the above are satisfied, will the tooltip be created
on that element. We store a reference to the DOM node that the tooltip
should be created on, then use this to perform tooltip actions via
jQuery. If this element gets changes (e.g. the tooltip content is
updated to another element) then the tooltip will be recreated.
If any of the first 3 requirements are not satisfied, an error will
be thrown to alert the developer to their misuse of this component.
To make this work, we do need to overwrite the title attribute of
the element with the tooltip, but this is the only solution other than
specifying `title` as an option when making the tooltip, but this is
not accessible by screenreaders unless they simulate a hover on the
element.
* Add warning about component overwriting `title` attr
* Update previous uses of Tooltip component
Frontend extenders exist in a weird state of limbo, where they are technically defined, but aren't used or tested at all. In da5db714c2, we shifted from passing `extension.extend` to `flattenDeep` to calling `flat` on `extension.extend`. If an extension doesn't define extenders (as is the case for most extensions), the change breaks the forum. All we do here is add a null check.
* Remove `lodash-es` dependency
* Replace `escapeRegExp` with home-made util
* Replace `throttle` with `throttle-debounce` library
* Use native browser methods for `deepFlatten`
We need a polyfill for iOS 11 and below. I think using a native method with this polyfill is better than having our own function instead, even if the bundle size is ~150B more.
* Save a few bytes in `escapeRegExp`
* Fix typo in comment
* Undo import re-organisation
* Use spread instead of slice
* Use smaller Array.flat polyfill from MDN
* Export new utils in `compat.js`
