https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38164
--- Comment #26 from Victor Grousset/tuxayo <[email protected]> --- (In reply to Jonathan Druart from comment #17) > (In reply to Victor Grousset/tuxayo from comment #14) > > Created attachment 172762 [details] [review] [review] > > Bug 38164: Update yarn.lock for removal of po2json.js > > Skipped this patch, this is a task for RM/RMaints. Right, that makes sense especially with backports and changes due to yarn versions. Like SCSS and DBIC. Not a problem then. Still something to keep in mind because having to sync yarn.lock after package.json changes isn't mentioned. https://wiki.koha-community.org/wiki/Release_management https://wiki.koha-community.org/wiki/Release_maintenance Especially since xt/verify-yarnlock.t doesn't cover this case (opened Bug 38170 for that) ----- (In reply to Tomás Cohen Arazi (tcohen) from comment #22) > (In reply to Jonathan Druart from comment #20) > > IMO we are only postponing the problem to the next time we will need yarn. > > I think this patch should target 24.05. And we should find a solution for > 24.11 Are we talking about finding a solution about fuzzy strings or "the next time we will need yarn" as in the next time a node package would be of use for us in production? It seems you both weren't in the same issue. As for the fuzzy strings thing, the fixed po2json.pl might be enough. VS po2json.js which has a similar amount of code as our .pl but even 1.0.0-beta-3 has dependencies on fixed versions https://npmgraph.js.org/?q=po2json%401.0.0-beta-3 po2json.pl has also dependencies on stuff that isn't on fixed version but that doesn't look much maintained: https://metacpan.org/pod/JSON https://metacpan.org/pod/Locale::PO Maybe it's ok, it's just interfaces for reasonably simple file formats. Anyway both are not in a great shape themselves and the dependencies they use (.pl => the dependencies themselves, .js => the fact that they are fixed). The biggest difference is po2json.pl can be maintained by us without having to fork it (it already is) and is easier to integrate into Koha (it already is) than a node lib. If we find a non trivial advantage for one, that could easily supersede the above IHMO. Especially if we are sure we will end up having to use node libs in production. -- You are receiving this mail because: You are watching all bug changes. _______________________________________________ Koha-bugs mailing list [email protected] https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
