What's up with package.json in plugins?

Development
5

Thanks @lzap for the post, there is a lot of things to do better,
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 :stuck_out_tongue: but as I said it’s not one person or one group to handle it.

What is package.json for?

Do we need it for development?

For production?

Basically, it’s the same as the Gemfile for Rails,
in development you need it for testing, linter, building the frontend code on changes,
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.

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?

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

Can core provide some kind of “standard” package.json for all plugins? Or at least some base dependency that can be imported by all?

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.

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.

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?

foreman-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. one solution could be to use @theforeman/vendor >= version so it will accept all versions above, or @theforeman/vendor: '*' to accept all.

If I compare to Ruby, it’s much better experience:

  • We have a Gemfile

There’s package.json

  • We pin most (all) gems in the Gemfile

Foreman-js does it for us

  • We do not commit Gemfile.lock into the git because we already did the job in the Gemfile

package-lock.json is also ignored

  • Plugins simply require foreman gem dependency to get all the dependencies

that’s something I would like to see in plugins as well, but basically we also use foreman-js for it,
but I would like to avoid the 1.5 GB in each plugin.

  • Plugins add unique dependencies on their own

that’s also achievable with pagack.json of plugins today, not that I would encourage it too much.
there is a post-install script in foreman that looks for all of the plugins and install their node-modules.

  • As long as Gemfile and gemspec is okay, packaging is relatively easy

I believe that as long as the plugin just use all the foreman-js supported modules, and accepts any version of foreman-js, then packaging is also very easy.

2 Likes