This blog post is the second in a series of posts related to the release of NodeBB v2.
The last time we provided an update on our roadmap was in late February of 2020. Development has ebbed and flowed (usually in response to paid client work… something to be said about putting food on the table, etc.), but we’ve always tried to make time for contributing back to the open-source core if and whenever time permits.
That said, it’s been far too long since an update was provided, so much so that people wonder if v2 will ever be released — so what exactly happened?
Essentially, we bit off more than we could chew. We wanted to tackle every bit of technical debt that had accumulated over the years, all at once. Unfortunately, there were too many moving parts, and as development continued in parallel with v1, the branches diverged more and more, to the point where it was no longer at a state that could be merged back in.
While we achieved some of the things we set out to do, there were other features that were left behind in the branch, languishing away. Waste not! Let’s see what we can do about that.
What we’ve accomplished
When we realized that the branches had diverged severely, we immediately began to port some of the completed work back into the main development branch, one-by-one. In addition to a seemingly endless list of bug fixes and new features, the following stand out as items that we had set out to do for v2, but were later merged into the current v1.x releases:
- Upgraded to FontAwesome 5 (thanks @oplik0!)
- Continued evolution of our eslint enforcement (thanks @pitaj!) and migration to a standalone eslint configuration (thanks @antosik!)
- Migration of the Write-enabled API into core, from the external plugin that I had maintained myself, along with automated testing for both Read and Write APIs
- Tests for our translation strings (a good base for our future efforts to standardize the format of translation keys)
Getting these items out of the way were already a relief to the ever-growing technical debt, so kudos to the entire team (and all of our external contributors!) for the hard work.
Roadmap Planning Meeting
On the 14th of February, the core team got together to talk through the pre-existing work on the v2 branch, and how to move forward — specifically, we wanted to finally have an answer to “when will NodeBB v2 be released?” and a response to “is NodeBB v2 dead?” that wasn’t just a simple “no”.
We wanted to look critically at the progress we’ve made since that last roadmap meeting, and to set the stage for continued development for the next few years. To that end, we’ve put together this blog post to briefly go over what we’re working on, and what we hope to deliver for v2 and beyond.
v2 (Webpack 5)
For awhile now, we’ve wanted to replace out ageing RequireJS/AMD implementation with Webpack. Baris spent quite a bit of time integrating Webpack 4 with our codebase, but that work was left behind back in 2020.
Technically, we’re quite late to the game. Webpack is now the de facto standard module bundler in use, and we’re happy to join the crowd as Webpack itself has matured nicely. Additionally, many third-party libraries began publishing their code onto npm, which means integrating with webpack is actually slightly easier than it was back in 2020.
Migrating to Webpack 5 will resolve growing pains we experienced trying to shoehorn third-party modules into our Require.js configuration. Additionally, we’re seeing a marked shift away from AMD. More and more developers are familiar with webpack, and it is time for change.
The important message we wanted to get across is that our focus for v2 will be minimizing deprecations, with no stylistic changes between v1 and v2. This work is foundational, and sets the stage for future milestones.
We made this decision since we wanted to minimize breakages into manageable chunks. The shift to webpack is already significant enough to warrant a major version bump.
Any custom themes and plugins written against v1 should “just work” with v2. Occasionally, some fixes will be required, especially if they involve AMD modules and window globals. Knowing that, a migration guide will be published alongside (or in advance of) the release of v2.
v3 (SASS, front-end framework decoupling)
NodeBB version 3 will bring about the deprecation of stylesheets written in LESS, in favour of SASS. As part of this change, we will be rewriting all of the Persona theme to use SASS.
This is meant to be a soft deprecation only! LESS will continue to be supported until v4.
More importantly, however, is addressing the other significant pain point with theme development: being hamstrung to our frontend framework (Bootstrap 3).
In the years since we began, we’ve seen the release of Bootstrap 4, and soon, Bootstrap 5. Changes are significant in between versions, and upgrading this version in core would break every single installation. This is why we’ve been slow to upgrade this entire time.
Baris then had a stroke of genius — why not decouple the front-end framework from core, and have each theme supply the framework as needed?
If a theme developer wanted to use Tailwind, Foundation, or Picnic, they should be free to do so, without conflict from another front-end framework.
To that end, we will be creating a set of new “base” themes that are not meant to be used as standalone themes. They will contain only a minimal set of common templates (e.g. partials, js boilerplate, modals, etc.) and be built against a specific framework.
From there, new themes would only need to set one of these base themes in their
baseTheme property in their
theme.json, and the appropriate front-end framework will be loaded, along with the minimal set of templates.
For example, instead of
nodebb-theme-persona being a standalone theme, we would have it inherit from the base theme
nodebb-theme-base-bootstrap3. Any pre-existing themes using
nodebb-theme-persona as their base theme should still continue to work.
This clears the path for us to start work on a new default theme, based off of bootstrap 5 or some other to-be-determined framework, while ensuring that any existing themes do not break. Neat, huh?
Simply put, by no longer being tied to a specific front-end framework, we hope to incentivise creation of additional themes.
What of version 1?
As stated before, version 1 will continue to be supported via backported security updates. All new functionality and development will continue on the v2.x branch.
So, when will v2 be released?
NodeBB v2.0.0 has a target release date of Q2 2022. A more defined date will be provided as development continues (and will be reported in our milestones page.)
What do you think?
Here’s your chance to provide feedback for us. Do you agree with our plan of attack for version 2? What do you want to see in future versions of NodeBB?
Cover Photo by Karsten Würth on Unsplash