action #71476
closedcoordination #154768: [saga][epic][ux] State-of-art user experience for openQA
coordination #157510: [epic] Up-to-date JavaScript stack
Migrate from AssetPack to Webpack
Description
Motivation¶
openQA currently uses Mojolicious::Plugin::AssetPack
for asset management. That module has mostly been obsoleted by Mojolicious::Plugin::Webpack
though, and is no longer particularly well maintained. I suggest we consider moving to the newer plugin before we actually run into serious issues. I'm opening this ticket because i ran into an incomprehensible error message from Mojolicious::Plugin::AssetPack
in another project, which turned out to be a missing dependency that was declared as optional in the Makefile.PL
and not referenced in the error message. Fairly annoying problem to track down.
Acceptance criteria¶
- AC1: DONE:
Mojolicious::Plugin::Webpack
and its dependencies have been packaged and added to Factory - AC2:
Mojolicious::Plugin::AssetPack
has been replaced withMojolicious::Plugin::Webpack
in openQA
Suggestions¶
- DONE:
submit https://build.opensuse.org/package/show/devel:languages:perl/perl-Mojolicious-Plugin-Webpack to openSUSE:Factory - DONE:
wait for inclusion in Factory - replace all references of "AssetPack" (also look case-insensitive) within the openQA source code
- also check manually that a startup of the openQA server works and everything is displayed correctly
Updated by okurz over 4 years ago
- Description updated (diff)
- Category set to Organisational
- Status changed from New to Workable
- Target version set to future
thank you this makes sense. I will not consider for the current backlog though. Good to have this ticket as reference and whenever we stumble upon any further issue with assetpack we can come back here.
Added suggestions to make it "Workable". Also the submission to Factory is easy. Done that now with:
osc sr -m "Initial submission, potential further dependency for openQA" devel:languages:perl perl-Mojolicious-Plugin-Webpack openSUSE:Factory
Updated by okurz about 4 years ago
- Status changed from Workable to Blocked
- Assignee set to okurz
I will track the SR
Updated by okurz about 4 years ago
- Description updated (diff)
- Status changed from Blocked to Workable
- Assignee deleted (
okurz)
https://build.opensuse.org/request/show/835321 accepted, https://build.opensuse.org/package/show/openSUSE:Factory/perl-Mojolicious-Plugin-Webpack is in Factory, AC1 and first task fulfilled.
Updated by mkittler almost 4 years ago
- Status changed from Workable to In Progress
- Assignee set to mkittler
- Priority changed from Low to Normal
- Target version changed from future to Ready
I'll give it a try considering Mojolicious::Plugin::AssetPack
does not support the current version of Mojolicious
.
Updated by mkittler almost 4 years ago
- Status changed from In Progress to Workable
- Assignee deleted (
mkittler) - Priority changed from Normal to Low
- Target version changed from Ready to future
Likely we're better off patching Mojolicious::Plugin::AssetPack
for the moment because this task seems to be more involved than just changing a few lines of Perl code:
Mojolicious::Plugin::AssetPack
andMojolicious::Plugin::Webpack
use completely different underlying technologies.- Webpack seems to focus on using either ES Modules, CommonJS or AMD but we use neither of those so far.
- Webpack is a nodejs application so a lot of nodejs modules need to be downloaded (~ 120 MiB). I suppose that's only required at build-time but still something we need to consider (e.g. adjust the documentation and environments where
generate-packed-assets
runs).
- The automatic conversion from
assetpack.def
provided byMojolicious::Plugin::Webpack
did not work in our case. The resulting configuration leads to many errors and is generally not working out-of-the-box. - So far we're generating assets to be bundled when building the RPM package and within the CI via
openQA/tools/generate-packed-assets
which also needs to be adjusted to work withMojolicious::Plugin::Webpack
.- This includes updating https://build.opensuse.org/package/view_file/devel:openQA/openQA/update-cache.sh
- The dependencies need to be updated but that's more than usual because there are AssetPack-specific cases.
Updated by okurz almost 4 years ago
- Target version changed from future to Ready
ok, good that you tried and evaluated already. However I still think now is a good time because after finding a short-term fix we need to be prepared and should not be "surprised" again the next time when we would not have the capability to invest into a proper solution at that time.
Updated by livdywan almost 4 years ago
kraih wrote:
Motivation¶
[...] I suggest we consider moving to the newer plugin before we actually run into serious issues.
I guess we missed that chance.
mkittler wrote:
I'll give it a try considering
Mojolicious::Plugin::AssetPack
does not support the current version ofMojolicious
.
Just to clarify, do we expect AssetPack to get updated at all? How unmaintained is it? Would it make sense to fix it upstream?
Updated by kraih almost 4 years ago
cdywan wrote:
Just to clarify, do we expect AssetPack to get updated at all? How unmaintained is it? Would it make sense to fix it upstream?
The author of Mojolicious::Plugin::AssetPack
does not care about the module anymore and is still looking for a new maintainer. If he will merge the PR Marius opened (and release a new version) is unclear. Moving forward we should assume the worst though, and consider the module abandoned. Serious issues will probably not be resolved in a timely manner.
Updated by okurz almost 4 years ago
- Status changed from Workable to Feedback
- Assignee set to okurz
there's a new Mojolicious::Plugin::AssetPack on CPAN, with Marius Kittler's test fix PR applied. https://build.opensuse.org/request/show/873696 was created and already accepted. Pending submission to openSUSE:Factory with https://build.opensuse.org/request/show/873701 . Will track that
Updated by kraih almost 4 years ago
To make the migration a little easier i'll see if the custom asset pipe code we have can be removed. https://github.com/os-autoinst/openQA/pull/3744
Updated by okurz almost 4 years ago
- Status changed from Feedback to Workable
- Assignee deleted (
okurz) - Target version changed from Ready to future
The mentioned SR is accepted, https://github.com/os-autoinst/openQA/pull/3744 is merged. So I assume we should now look into the next parts of a migration following up to #71476#note-6, right?
Updated by kraih almost 4 years ago
The maintenance status of Mojolicious::Plugin::AssetPack
is open again and discussions are happening upstream (it might even get un-deprecated). So there's a chance that we don't have to migrate to webpack at all if we don't want to. It will probably take a few more days to figure out the details though.
Updated by okurz almost 4 years ago
Ok, cool. @kraih can you point us to the place where we could follow the discussion and eventually decisions about the maintenance status? If not then please take the ticket and update with more news as you have them. Thanks!
Updated by kraih almost 4 years ago
okurz wrote:
Ok, cool. @kraih can you point us to the place where we could follow the discussion and eventually decisions about the maintenance status? If not then please take the ticket and update with more news as you have them. Thanks!
It's private, i'll keep the ticket updated.
Updated by kraih almost 4 years ago
- Status changed from Workable to In Progress
Mojolicious::Plugin::AssetPack
is now maintained in the mojolicious org on GitHub, so if necessary i can fix any issues we run into. :) https://github.com/mojolicious/mojolicious-plugin-assetpack
Updated by kraih almost 4 years ago
- Status changed from In Progress to Feedback
My original reasoning for requesting the change is moot now. So we should re-evaluate if we still want to use webpack instead of assetpack. The main reason to do so would be better JavaScript compilation features. For React, Svelte... and the like. But we don't need that at the moment. So, if nobody has a good reason i'd just close this ticket.
Updated by okurz over 3 years ago
- Status changed from Closed to Resolved
- Target version changed from future to Ready
Updated by kraih about 2 years ago
Since i'm pretty sure we will be revisiting this in the future, i'll mention that i've recently converted Cavil from AssetPack to Webpack, and the same approach would probably also work for openQA.