JavaScript libraries bundling

[nijel]

Describe the problem

Right now, Weblate uses custom tooling to include vendored libraries (see https://docs.weblate.org/en/latest/contributing/frontend.html#dependency-management). This is tricky to deal with for new contributors and brings issues when updating some libraries (see for example https://github.com/WeblateOrg/weblate/actions/runs/10178733602/job/28152952153?pr=11956 in https://github.com/WeblateOrg/weblate/pull/11956).

Describe the solution you would like

There should be some standard solution that works for us. Requirements (those can be discussed, though):

• No additional runtime or installation time requirements besides Python modules.
• Store only needed files in Git, not full vendored packages.

Describe alternatives you have considered

Things like webpack could be a solution. It might also replace the currently used django-compressor.

Screenshots

No response

Additional context

List of libraries to migrate:

• [ ] @tarekraafat/autocomplete.js
• [ ] autosize
• [ ] daterangepicker
• [ ] mousetrap
• [ ] mousetrap-global-bind
• [ ] multi.js
• [ ] prismjs
• [ ] slugify
• [ ] source-code-pro
• [ ] source-sans
• [x] tributejs

Libraries which probably won't be migrated:

• bootstrap-rtl as we use a newer snapshot than the release available as a package
• boostrap is using customized build

Maybe we should focus on #2916 instead.

[meel-hd]

@nijel This will be a big improvement.

To sum up, currently used 3d party code is included in the app by weblate/templates/base.html by more than a dozen script tags. linking to large 3rd party library files. Which are installed by yarn and copied using custom tooling into static/vendor.

So given the desired results here it is what we will have:

• Ease of install and update (one command yarn install library).
• Familiar to new contributors (The same usual workflow used by the web dev community using npm/yarn, with no need for custom tooling.)
• Installs will be stored in the gitignored folder node_modules.
• The use of the 3rd party code in static/vendor will be unnecessary and can be removed.
• There will be one source of truth for declaring the use of third party code.

How: 1- We will introduce a new directory vendor/ for managing frontend 3rd party code. 2- It will contain the index.js, package.json, yarn.lock, webpack.config.js and the gitignored node_modules/. 3- index.js Will be used to import the libraries necessary for the frontend. And remove them if needed too. 4- Webpack will be used to build and bundle the libraries used and declared in index.js into a minified file. 5- The resulted .js file will be included into the base.html template. To make it available for the parts that needs it.

**Visual Representation: **

Some questions:

• What bundler we should use (the most well known ones are webpack, vite, parcel, and rollup).
• I am not sure if we should git track the output .min.js file.
• How to integrate this in the Docker workflow.
• Adaption of this will be on one time or gradual.
• And at last. did I miss something or there is some possible better solutions?

[nijel]

1- We will introduce a new directory vendor/ for managing frontend 3rd party code.

How about placing it under client to make it clear this is client-side code?

* What bundler we should use (the most well known ones are webpack, vite, parcel, and rollup).

Recommendations are welcome.

* I am not sure if we should git track the output `.min.js` file.

Probably yes, so that install from Git works without building the js files.

* How to integrate this in  the Docker workflow.

This is another reason to have .min.js files in the Git, the snapshot containers are installed using that.

* Adaption of this will be on one time or gradual.

I'd start with the migration of a few libraries as a proof of concept. How about starting with Sentry (which needs building anyway) and fonts (to make sure that assets are handled correctly).

* And at last. did I miss something or there is some possible better solutions?

[meel-hd]

Uh true the name client is better.

For the bundler I would recommend Vite since we are going to track the output file with git. It produces Smaller bundles in comparison to the others. Also it is known for its speed which makes the developer experience better. Moreover it supports Hot module reloading if we add rebuilds on changes for the frontend in the future, it will be already available.

Other things I think are great I will continue with it from here. I will implement this starting with sentry.

[github-actions[bot]]

This issue has been automatically marked as stale because there wasn’t any recent activity.

It will be closed soon if no further action occurs.

Thank you for your contributions!

[nijel]

@meel-hd I've added list of deps into initial comment, I think now it's time to address theme one by one.

[meel-hd]

@nijel in progress. #12731 continues with TributeJs

[meel-hd]

Since tribute.js has been moved to the new build workflow in #12731. Working on moving @tarekraafat/autocomplete.js

[github-actions[bot]]

Thank you for your report; the issue you have reported has just been fixed.

• In case you see a problem with the fix, please comment on this issue.
• In case you see a similar problem, please open a separate issue.
• If you are happy with the outcome, don’t hesitate to support Weblate by making a donation.