Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update JS stack #2125

Open
ialarmedalien opened this issue Feb 8, 2021 · 0 comments
Open

Update JS stack #2125

ialarmedalien opened this issue Feb 8, 2021 · 0 comments

Comments

@ialarmedalien
Copy link
Collaborator

Originally started by looking at transitioning from Jasmine/Karma to Jest. Jest does not support requirejs; possible solutions would be to mock out requirejs for testing, or to convert modules to CJS or ES6 format. We would need to replace instances where we use requirejs to load non-JS files; looking through the develop branch, our usage includes:

  • json files: mostly config files; could easily be converted to .js files
  • css files: largely replaced by moving to a single JS file for all the kbase css; the other CSS files that are commonly used are Font Awesome and Google code prettifier. These could be added to the set of css files loaded by in the standard page template.
  • text files: almost all are template files. Investigation required, but it may be that Handlebars (template library) has a function that takes a file URL, rather than a text string.
  • yaml files: use js-yaml or a similar library to parse these

We also use requirejs to load libs in the ext_components directory; I haven't investigated all these in detail yet.

If we are going to move to jest, I would suggest abandoning AMD / requirejs completely and moving to using ES6 module format, with appropriate shims for legacy browsers. There are a number of migration scripts that would make it fairly easy to move, especially if we dealt with the non-JS files first.

We could then move to using Webpack (other alternatives exist, but webpack is probably the most popular and best supported) for JS bundling; if we are going to do that, we could get rid of bower, which would make maintaining JS deps much simpler. 🎉 😁

We may want to consider creating different webpack bundles according to which assets a page/module needs. It would probably be wise to create separate bundles for browsers with less support for ES6+ features (although getting browser usage data might be helpful in deciding what is/isn't worth supporting).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant