RFE: Create and publish a proper NPM package

[kahowell]

This would make development of out-of-tree cockpit plugins far easier. For example it would make work such as that in candlepin/subscription-manager#1709 unnecessary (i.e. since cockpit developers have already done all the hard work of getting the bootstrap-select component to work in pure React, it'd be wonderful to simply take advantage of that). I tried a few things to import cockpit JS as a dependency in that PR and hit many blockers, since the project is really not structured for that (the last one I recall is some relative paths causing issues).

Another way to have a similar effect is to push some of the code upstream. For example, if some of the react components such as cockpit-select were integrated into patternfly-react, this would have a similar effect.

Related: patternfly/patternfly-react#54

[petervo]

@kahowell, yes we've discussed this a number of times. Here is where we are at.

Anything in base/ is supported and guaranteed to be backwards compatible. We do not publish npm packages for anything there though. It needs to be loaded from the server so that the version of cockpit.js you get matches the bridge it is running on. You are probably already be familiar with doing that.

However, for the js in lib/ we aren't really comfortable supporting it forever yet. The code there does change from time to time and not in a backwards compatible way. Your best bet for now is to just copy the files you want from lib into your project.

[kahowell]

@petervo, I understand; thanks for the insight. I looked into copying some of the files, and there is some tight coupling that makes it hard to do without a lot of work to identify and pull in additional files and/or rewrite/refactor the dependencies out (I don't recall specifics at the moment, but could look back and provide specifics if you're curious).

Is there any plan to contribute some of the react components specifically upstream to patternfly-react? That's another way to achieve the spirit of what this RFE is about (for subscription-manager at least).

For example, we identified three specific components that would be useful for us specifically:

• pkg/lib/cockpit-components-select.jsx
• pkg/lib/cockpit-components-listing.jsx
• pkg/lib/cockpit-components-dialog.jsx

edit: grammar

[petervo]

@petervo, I understand; thanks for the insight. I looked into copying some of the files, and there is some tight coupling that makes it hard to do without a lot of work to identify and pull in additional files and/or rewrite/refactor the dependencies out (I don't recall specifics at the moment, but could look back and provide specifics if you're curious).

Yes please do. We'd like to make these easy to copy, so any problems you ran into would be helpful to know about and we can try to fix them here.

Is there any plan to contribute some of the react components specifically upstream to patternfly-react? That's another way to achieve the spirit of what this RFE is about (for subscription-manager at least).

There hasn't been so far, mainly because we don't use patternfly-react. Last time we looked into it we didn't want to bring it in as it was pretty heavy weight with a lot of deps. But it's probably worth looking into.

[kahowell]

I don't recall specifics at the moment, but could look back and provide specifics if you're curious

@petervo I had a TODO sitting around for quite a while for this...

Here goes:

• We copied cockpit-components-dialog.jsx, not too many tweaks were needed (see https://github.com/candlepin/subscription-manager/blob/3676b73222aac38178539d208784c3bccbb54f27/cockpit/src/cockpit-components-dialog.jsx compared to https://github.com/cockpit-project/cockpit/blob/07aa4442839211339c328c3cbce259a1cfe1dfe6/pkg/lib/cockpit-components-dialog.jsx)
• We opted to just replace cockpit-components-listing.jsx w/ ListView from patternfly-react, as it required some styles which were defined in listing.less, which contained references to variables.less, which contains some relative imports... (paths starting with ../../node_modules). 🤔 I think this was the pain point for us that prompted me to open this issue. I think webpack should be able to handle paths in the less as "~${name_of_node_module}/path/to/less", like https://github.com/candlepin/subscription-manager/blob/3676b73222aac38178539d208784c3bccbb54f27/cockpit/src/subscriptions.css#L20, but there's still the issue of the depth of dependent files...
• cockpit-components-select.jsx we chose to replace, but I think this was just because we didn't want to carry around that amount of logic that might need maintenance... our current compromise (https://github.com/candlepin/subscription-manager/blob/3676b73222aac38178539d208784c3bccbb54f27/cockpit/src/Select/Select.jsx) is more hacky and involves jQuery, but it's much less to maintain.

Anyways, we reached a state where we're relatively happy with the various solutions... Hope this info helps cockpit devs or others following a similar path.

I still think it'd be nice to have an NPM package for reusable react components from cockpit (or get them into patternfly-react), but subscription-manager-cockpit is in an okay state without it.

[martinpitt]

In Cockpit itself we are aiming for moving to PatternFly-React components, and we encourage others to do the same. Honestly defining a public stable API for these shared components is just too cumbersome -- if you want to use them, it's easier to just copy and adjust them.