Dev Diary: Build 19

v1.1 was just released 🥳

Time for a new dev diary, with the hopes of making this a bit more active than the last one 👍️

Nice, looking forward to checking it out and upgrading!

Starting off this dev diary, I'm excited to announce that we've rewritten docs.flarum.org to use Docusaurus instead of Vuepress. This change gives us a lot of useful features, like an autogenerated ToC on every page, better SEO, and most importantly, first-class support for internationalization. It's now much easier to manage docs translations.

Alongside this change, we will now be coordinating documentation translation via Crowdin. After registering, you'll be able to contribute translations via a convenient API.

Finally, we've expanded our docs homepage, and added new dev and translation/doc contributing docs that explain how you can help Flarum.

askvortsov The new docs site is beautiful!

askvortsov Now Flarum's docs have better SEO than Flarum itself 🤣 🤣 😅

Zeokat Now Flarum's docs have better SEO than Flarum itself

This made me laugh pretty hard but I do feel like Flarum gets a bad rap on SEO.

I feel like I do pretty decent in search, and working for that link juice from other websites I think has helped more than anything other than writing pretty long form content on my flarum. Don't get me wrong there are SEO things I would love to see implemented in flarum, but I think a lot of people focus on these small SEO details and ignore the bigger things that they can affect now themselves.

We just released v1.1.1 of the mentions extension that fixes a bug with autocompleted user mentions not properly working with the new format.

https://github.com/flarum/mentions/releases/tag/v1.1.1

composer update flarum/mentions

We had our start of build cycle meeting today and it was incredibly productive.

A lot of what we discussed was around the way we work and how we plan to work in the future so that not only can we bring awesome features and focus on what's important, but also so that we as developers can be more excited about what we're working on so we prevent some of the burnout we experience.

We also discussed a lit bit about documenting some our internal processes and making some of our policies/procedures more clear and publishing them publicly so that anyone can review them.

That's all I have to say for now, stay tuned to this diary for more updates as we work. Our goal is to use this more than we did the previous release cycle so that everyone is informed.

Just an update from me since it's been awhile since anyone did any updates here,

I've been working on getting phpstan up and running for Flarum. This will hopefully help us find issues before they actually happen along with overall helping us write some better code. It's still very early though and there are a ton of issues to work out.

tankerkiller125 Are projects like the PHPStan integration typically collaborative or something worked on privately until it's complete? I briefly poked around to see if I could find where it was happening or what the issues are and came up empty.

linc Generally we start these project locally on our own, sometimes we will do live code edit sessions internally and publish the branch later.

For this particular goal of ours I worked on it internally for a bit to get things at least working and pushed the branch just recently. So the branch for this is https://github.com/flarum/core/tree/mk/phpstan and the issue itself for the project is flarum/core3105

tankerkiller125 Thanks! Is the current goal to repair/work around all 109 level-4 errors before you merge that automation?

linc Right now the goal is to fix errors that are legit, and work on building stubs for Flarum that actually work so we can get rid of the baseline file, and then work on increasing the phpstan level.

I've mainly been focusing on improvements for developers in this release cycle.

We've recently migrated to the Yarn package manager within core. In the past, we've noticed a fair number of issues around npm and how it behaves across platforms, and sometimes just on different days!

[RANT] For example, there was a recurring issue for me where npm couldn't resolve "chokidar", which is absolute nonsense as the package was installed and present in node_modules. Furthermore, Flarum CLI has played tricks on us when installing with npm i -g in the past, with yarn add --global or yarn dlx being fine.

One of the requirements to switch to Yarn was Plug'n'Play package manager support. Newer versions of Yarn (2+) use PnP by default in new projects, which had some incompatibilities with our webpack configuration. This was fixed in flarum/flarum-webpack-config14. We don't use PnP in core at the moment, and don't plan to for a while yet (see flarum/core3155).

Please note that you won't be able to update to v2 of our Webpack config until Flarum 1.2 releases, as we have upgraded to Webpack 5 thanks to @askvortsov! Webpack 4 extensions will continue working alongside newer Webpack 5 extensions, for the near future.

Alongside the Yarn migration, I've also been working on the usual Typescript conversions, accessibility improvements and the occasional bug fix:

• flarum/core3090 [A11Y] Improve accessibility for discussion reply count on post stream
• flarum/core3132 chore: better typings for DiscussionListState
• flarum/core3137 chore: rewrite SubtreeRetainer into Typescript
• flarum/core3139 fix: issue with CSS styles when in-between whole pixel values for viewport width
• flarum/core3147 feat: allow use of any tag in listItems helper

Have you guys also tried pnpm? In my experience it works better than npm and is faster than yarn v1, I only had issues using it (and used yarn instead in that specific project) with assemblyscript stuff.

wonderbeel

I would only feel comfortable using either npm or Yarn personally, because they are the most popular offerings and fairly well-known.

We've just released updates for two of our bundled extensions, flarum/mentions (v1.1.2) and flarum/emoji (v1.1.1)!

Mentions

Fixed

• Only search users via rest API if user has permission by @askvortsov1 in flarum/mentions73
• fix: Cannot reply to posts by deleted authors by @SychO in flarum/mentions75
• fix: autocomplete errors with TextEditor re-use by @davwheat in flarum/mentions77

Full Changelog: https://github.com/flarum/mentions/compare/v1.1.1...v1.1.2

Emoji

Fixed

• fix: errors with composer reuse by @davwheat in flarum/emoji42

Full Changelog: https://github.com/flarum/emoji/compare/v1.1.0...v1.1.1

To update, run:

composer update flarum/mentions flarum/emoji

davwheat

Another quick update for flarum/mentions, bumping it to v1.1.3.

Added

• chore: add missing compat exports and extensibility by @gianniguida in flarum/mentions76

Fixed

• fix: errors on texteditor re-use again by @davwheat in flarum/mentions78
• fix: allow mentions from non-post objects by @IanM in flarum/mentions79

Full Changelog: https://github.com/flarum/mentions/compare/v1.1.2...v1.1.3

This release fixes an incompatibility which prevented the use of mentions in some third-party extensions, such as FoF Moderator Notes and FoF Pages. If you use extensions which need mentions in any location outside of posts, you should update to v1.1.3.

Wanted to share an update as well. I've been working on opening and reviewing a lot of pull requests so far this release cycle. A few particularly interesting ones:

1. Typescript typecheck and type coverage automation (PR).Typescript is a programming language that extends JavaScript with types. It allows running type analysis on code before compilation to ensure that no type errors are possible. This makes it a lot easier to write correct code, and be sure that your code is good. Flarum's core has been converting from JavaScript to TypeScript for a while, and while there's quite a bit to go, this PR adds GItHub actions that automatically check for typing errors, and analyze the codebase to see how much of the program is protected via types. In the future, we hope to make these tools easily available to extensions via Flarum CLI.
2. Support setting nicknames on registration (PR). A long-standing complaint about Flarum is the fact that usernames can only have ASCII characters, which makes using it on non-english-speaking communities unideal. Last year, we released the Flarum nickname extension, allow users to set a nickname with arbitrary characters. In the next release, we've added the ability to set nicknames as part of registration, along with an option to automatically generate usernames so users don't need to worry about usernames whatsoever.
3. The confusing "Uninstall" button on extension pages has been renamed to "Purge" to reduce confusion.
4. Webpack 5 is now supported in extensions (PR).

Among some other small fixes and features. I'm hoping to keep improving our TypeScript setup, and migrate a lot of changes back to flarum-cli so they're easy to use in your community extensions.

On a team level, we also have some big changes coming soon, so stay tuned!

askvortsov The confusing "Uninstall" button on extension pages has been renamed to "Purge" to reduce confusion.

Whats does "Purge" do?

askvortsov 2. Support setting nicknames on registration

This is a simple but great UX change, we've had a few users asking, for example, why they can't have spaces in a name, when they can see that other people have them. A lot of people won't go to their profile and notice the ability to change nickname, so this makes a lot of sense.

MikeJones Same thing as before, it rolls back all migrations

MikeJones askvortsov ...which in practice means removing the extension data from the database