Project

General

Profile

Actions

action #71476

closed

coordination #154768: [saga][epic][ux] State-of-art user experience for openQA

coordination #157510: [epic] Up-to-date JavaScript stack

Migrate from AssetPack to Webpack

Added by kraih over 4 years ago. Updated 7 months ago.

Status:
Resolved
Priority:
Low
Assignee:
Category:
Organisational
Target version:
Start date:
2020-09-17
Due date:
% Done:

0%

Estimated time:

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 with Mojolicious::Plugin::Webpack in openQA

Suggestions

Actions #1

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

-> https://build.opensuse.org/request/show/835321

Actions #2

Updated by okurz about 4 years ago

  • Status changed from Workable to Blocked
  • Assignee set to okurz

I will track the SR

Actions #3

Updated by okurz about 4 years ago

  • Description updated (diff)
  • Status changed from Blocked to Workable
  • Assignee deleted (okurz)
Actions #4

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.

Actions #5

Updated by okurz almost 4 years ago

as discussed in chat, agreed.

Actions #6

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 and Mojolicious::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 by Mojolicious::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 with Mojolicious::Plugin::Webpack.
  • The dependencies need to be updated but that's more than usual because there are AssetPack-specific cases.
Actions #7

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.

Actions #8

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 of Mojolicious.

Just to clarify, do we expect AssetPack to get updated at all? How unmaintained is it? Would it make sense to fix it upstream?

Actions #9

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.

Actions #10

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

Actions #11

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

Actions #12

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?

Actions #13

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.

Actions #14

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!

Actions #15

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.

Actions #16

Updated by kraih almost 4 years ago

  • Assignee set to kraih
Actions #17

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

Actions #18

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.

Actions #19

Updated by kraih over 3 years ago

  • Status changed from Feedback to Closed
Actions #20

Updated by okurz over 3 years ago

  • Status changed from Closed to Resolved
  • Target version changed from future to Ready
Actions #21

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.

Actions #22

Updated by okurz 7 months ago

  • Parent task set to #157510
Actions

Also available in: Atom PDF