There is a post-install script in foreman that looks for all of the plugins and install their node-modules. That’s also achievable with pagack.json of plugins today, not that I would encourage it too much. Plugins add unique dependencies on their own.That’s something I would like to see in plugins as well, but basically we also use foreman-js for it,īut I would like to avoid the 1.5 GB in each plugin. Plugins simply require foreman gem dependency to get all the dependencies.We do not commit Gemfile.lock into the git because we already did the job in the Gemfile.If I compare to Ruby, it’s much better experience: one solution could be to use >= version so it will accept all versions above, or '*' to accept all. If we really need a separate package.json and node_modules per plugin, can we write a tool that would bump these automatically for plugin authors?įoreman-js works with semver and treats each version like other npm packages, which might not suite really for Foreman and plugins that don’t want to bump it always, and just accept the newer version of it. I also went over many plugins and reduced the dependencies they have in package.json so now there are plugins that don’t even have dependencies, just devDependencies. That’s the goal of foreman-js I believe, and it made the work much better as you don’t need to package each and every module your plugin uses, and you don’t need to care if Foreman core is using another version of your module, because on runtime it will use the core’s module and your plugin could break - all of that is already fixed. That’s something I really dislike, and hopefully, we could overcome it via using properly the assets-pipeline / module-federation - discussing it in Rails 7 and new frontend approaches POCĬan core provide some kind of “standard” package.json for all plugins? Or at least some base dependency that can be imported by all? I have a node_modules in each of my plugins, that is 1.3 GB per plugin is this correct? Is it possible to reuse this content?
In production, you need to build your plugin code and iiuc, when someone wants to install a plugin, e.g: yum install foreman-tasks all of the frontend assets should be already compiled. In development you need it for testing, linter, building the frontend code on changes,
It seems that our frontend build tools and configuration with Rails is made patch by patch to fix things that didn’t work, and to deal with it we need help from people who understand rails and the assets-pipeline, packaging, and frontend development, Rails is bringing updated approaches to frontend in Rails7 as detailed in Rails 7 and new frontend approaches POC and we must update our deprecated stack but as I said it’s not one person or one group to handle it.īasically, it’s the same as the Gemfile for Rails,
Thanks for the post, there is a lot of things to do better, I have a feeling that core already moves on when I perform some change to correct it: Clean up package.json by lzap Ĭan you recommend a good solution to this? It’s a mess for me, granted, I do not fully understand how this is supposed to work. There should be some tool that could maintain this, isn’t package.json similar to bundler that does the same job? Do we want to write some script or instructions for plugin authors to keep them clean?
I don’t particularly like catching up with dependencies manually, that is a time wasted. When dependencies are bumped in Foreman core, the ones mentioned in plugins do not match, but dev setup still do work fine somehow.īut then I hit problems when I try to perform package update (RPM), we have more strict rules and the packaging script carries versions over from package.json to SPEC. There are several plugins I currently maintain that have package.json now since some JS components were introduced. This is bugging me quite often now and I want to know more.