I’m working on updating foreman-js to test/run on node 18 (now only tests on node 14), and ran into this issue that node 18 openssl was upgraded to 3.0.0, which resulted in removing the support for legacy cipher algorithms. So to make it work on node 18 we need to run it with the --openssl-legacy-provider, or update foreman-js to Webpack 5.
From what I remember and read, we created foreman-js to:
avoid duplicates and need to rebuild plugins after each core build, we have not completely achieved that with foreman-js, but did achieve it in foreman core with Webpack 5
clarify the build process: over my time maintaining foreman-js it looks like the build is just complicated for me/others. The architecture is confusing, some fixes could be done in foreman core and in foreman-js or even plugins, and also every fix done in foreman-js is harder to test than fixes in foreman core since devs need to link foreman-js to foreman.
version control for plugins: I dont think this is really used as some plugins just list foreman-js (@/theforeman/vendor) as use latest in package.json and Katello just assumes its there and doesnt list foreman-js.
The update to Webpack 5 is proving to be time consuming and complicated, so my proposal is to run foreman-js with node18 and --openssl-legacy-provider, and after that work on removing parts/all of foreman-js.
Anyone is against this proposal (or parts of it) or have some insight that I missed?
As a developer of Katello I can say it would be a huge improvement in my developer experience if I didn’t have to deal with foreman-js. I think you’ve provided a great summary above and think we should move forward with removing it if possible.
EL 9 also comes with OpenSSL 3, so do Debian 12 and Ubuntu 22.04. While we haven’t set a formal timeline, I hope that around Foreman 3.13 those will be our only targets.
This is the big one. I think foreman-js tries to solve a problem that no longer exists.
I think some plugins try to support standalone mode, where you can use npm install and run the test suite. Today they can use foreman-js as a dependency to make that work.
I question whether it’s really valid at all, given you probably always need parts from Foreman core itself. Because of that I think foreman.git should replace the role that foreman-js previously took. Whether npm can actually do this is a good question, but if you can find a way to get provide a set of best practices (this is how you develop, test, etc) for plugin maintainers while also getting rid of foreman-js I think the world would be a better place.
I agree with these points and the tactic. I think a goal of this was also to centralize JS dependencies even if one off for a plugin to be in a single place and reduce packaging and JS dependency overhead. I don’t feel we delivered on that either.
Foreman core, based on our architecture, is the core requirement for any plugin and we should work from that model across the board and reduce friction where we can. I would encourage us to be vigilant to try not to overload the core and explode it’s size and set of dependencies while balancing centralization and friction reduction.
I would encourage us to be vigilant to try not to overload the core and explode it’s size and set of dependencies while balancing centralization and friction reduction.
I think we can achieve this with some automation: we can analyze plugin’s package.json files with core’s package.json and act according to the appearance of a package: if the package is in the core and only used by at most one plugin - it should be removed from core and referenced directly from a plugin. If a package is used by more than one plugin - it should be added to core.
Me, Shim, Ewoud and Karolina had a meeting on how to start going around this.
One of our concerns was plugin tests, we think we should make sure there are generic github actions for running npm test and npm run lint for plugins to use. We are also thinking about creating some npm run test:plugin plugin-name script so plugins can be tested easily from the foreman core dir, like we have rake test:foreman_remote_execution.
Also I’ll make a list for packages that are not being used/only used by one plugin, will post it, and will not move it to the foreman core. So when plugins remove “@theforeman/vendor” the github action that has npm install npm run lint, should notify them that they are missing a package (in most cases). A list of removed packages will be posted.
On a related note to package removal, I recommend for any JS UI file to not use any special packages, and use @patternfly/react-X for any UI, and use: react, react-router-dom, react-redux , prop-types, humanize-duration, lodash, as these packages should have everything for Foreman UI development.
The change will probably happen in a few steps in the foreman core, and in one step in each plugin once we’re done with core.
On the foreman plugin overview there’s a list of plugins that have JS tests. Clicking a few of them shows that they haven’t all migrated. Having this in place will make testing a lot simpler because we can then open a PR against foreman.git and a bunch of PRs to plugins using the Foreman PR, giving us a view of how it would look like once things are merged.
