action #71476
closed
Added by kraih over 4 years ago.
Updated 7 months ago.
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¶
- 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
- Status changed from Workable to Blocked
- Assignee set to okurz
- Description updated (diff)
- Status changed from Blocked to Workable
- Assignee deleted (
okurz)
- 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.
as discussed in chat, agreed.
- 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.
- 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.
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?
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.
- Status changed from Workable to Feedback
- Assignee set to okurz
- Status changed from Feedback to Workable
- Assignee deleted (
okurz)
- Target version changed from Ready to future
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.
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!
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.
- Status changed from Workable to In Progress
- 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.
- Status changed from Feedback to Closed
- Status changed from Closed to Resolved
- Target version changed from future to Ready
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.
- Parent task set to #157510
Also available in: Atom
PDF