Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-42602

Improve publishing and sharing of pure JS modules/libraries

    • Blue Ocean - 1.1-beta-1, Blue Ocean - 1.1-beta2, Blue Ocean 1.1-beta4, Blue Ocean 1.1, Blue Ocean 1.1, Blue Ocean 1.2-beta1, Blue Ocean 1.2-beta2, Blue Ocean 1.2-beta3, Blue Ocean 1.2-beta4, Blue Ocean 1.3, Blue Ocean 1.4 - beta 1, Blue Ocean 1.4 - beta 2

      Publishing of npm modules like core-js and jdl is error prone. 

      This could be automated away via tooling, or an alternative mavenised way of delivering shared should be invested in to speed up development and improve sharing of code. 

      Impacts on extensibility and plugin development. 

       

      cc cliffmeyers kzantow if there are always going to be pure JS modules, then perhaps we should split this in 2 - one for modularity/shared code and one for better publishing of vanilla npm modules - thoughts? 

          [JENKINS-42602] Improve publishing and sharing of pure JS modules/libraries

          Cliff Meyers added a comment - - edited

          I think the shape this ticket takes depends a lot on where we land w/ the extensibility work.

          I know kzantow and I have discussed that core-js could be largely obviated if "blueocean-personalization" could simply depend on "blueocean-dashboard" as a Maven dep, and then we had a little magic to pull the right JS dependencies downstream into node_modules. Then things like the Run/Replay buttons, the mobx services, etc could be used in both BO modules without being forced to put them in core-js.

          It seems to the follow then that "blueocean-dashboard" might depend on another plugin (perhaps "blueocean-web") that is providing all the necessary under the hood JS stuff (extension loading, React, etc). If someone wanted to build their own totally separate UI that had nothing to do with the BO UI, they'd just depend on "web" and not on "dashboard".

          To me, those are the changes that would impact plugin developers.

          But even if we manage to eliminate core-js, we still have the JDL which I'm not sure we'd fold into anything else (but could). And then we still have a lot of smaller JS libs like js-builder, extensions, etc which should all have a uniform way of being published.

          I know one tool we looked at was "release-it" to simplify and formalize NPM publishing. Whatever we land on, I think it should be as close as possible to process we use to release and publish Maven plugins.

          Cliff Meyers added a comment - - edited I think the shape this ticket takes depends a lot on where we land w/ the extensibility work. I know kzantow and I have discussed that core-js could be largely obviated if "blueocean-personalization" could simply depend on "blueocean-dashboard" as a Maven dep, and then we had a little magic to pull the right JS dependencies downstream into node_modules. Then things like the Run/Replay buttons, the mobx services, etc could be used in both BO modules without being forced to put them in core-js. It seems to the follow then that "blueocean-dashboard" might depend on another plugin (perhaps "blueocean-web") that is providing all the necessary under the hood JS stuff (extension loading, React, etc). If someone wanted to build their own totally separate UI that had nothing to do with the BO UI, they'd just depend on "web" and not on "dashboard". To me, those are the changes that would impact plugin developers. But even if we manage to eliminate core-js, we still have the JDL which I'm not sure we'd fold into anything else (but could). And then we still have a lot of smaller JS libs like js-builder, extensions, etc which should all have a uniform way of being published. I know one tool we looked at was "release-it" to simplify and formalize NPM publishing. Whatever we land on, I think it should be as close as possible to process we use to release and publish Maven plugins.

          Keith Zantow added a comment -

          Right, I definitely agree there are a couple related but separate issues here...

          One is that of code sharing, which the newer extension work should solve.

          The other is distribution both to developers and to Jenkins. Jenkins distribution is already solved by publishing plugins, which we could more granularly adopt. E.g. JDL could be published as a separate Jenkins plugin, as could React. In fact, it probably will be important to do that in order to make sure that it gets updated when installing newer plugins that depend on newer features from JDL, as long as we're explicitly including it web and forcing it out of other plugins.

          Distribution to developers, though, is a separate issue. Tools like VS: Code want node_modules properly populated to validate certain things, or often will barf with errors. We need to be able to run tests with some of the upstream code. So, as I mentioned in CA, I have ideas for both - and namely, if we do adopt more parity with plugin distribution, I have a prototype that can put code and typescript definitions in the right places in node_modules.

          But perhaps, we could just add some npm publishing during plugin publishing, if it made sense. At runtime, the upstream plugins would provide the code and the bundler would be modified to remove things provided by upstream plugins.

          This essentially eliminates needing to publish anything except for the plugins, and development on multiple plugins would work using hpi:hpl more seamlessly.

           

          Keith Zantow added a comment - Right, I definitely agree there are a couple related but separate issues here... One is that of code sharing, which the newer extension work should solve. The other is distribution both to developers and to Jenkins. Jenkins distribution is already solved by publishing plugins, which we could more granularly adopt. E.g. JDL could be published as a separate Jenkins plugin, as could React. In fact, it probably will be important to do that in order to make sure that it gets updated when installing newer plugins that depend on newer features from JDL, as long as we're explicitly including it web and forcing it out of other plugins. Distribution to developers, though, is a separate issue. Tools like VS: Code want node_modules properly populated to validate certain things, or often will barf with errors. We need to be able to run tests with some of the upstream code. So, as I mentioned in CA, I have ideas for both - and namely, if we do adopt more parity with plugin distribution, I have a prototype that can put code and typescript definitions in the right places in node_modules. But perhaps, we could just add some npm publishing during plugin publishing, if it made sense. At runtime, the upstream plugins would provide the code and the bundler would be modified to remove things provided by upstream plugins. This essentially eliminates needing to publish anything except for the plugins, and development on multiple plugins would work using hpi:hpl more seamlessly.  

          Michael Neale added a comment -

          Might be related to this WIP PR: https://github.com/jenkinsci/blueocean-plugin/pull/632 (or that may just be the decorator side of things).

          Michael Neale added a comment - Might be related to this WIP PR: https://github.com/jenkinsci/blueocean-plugin/pull/632  (or that may just be the decorator side of things).

          Michael Neale added a comment -

          kzantow please do enlist imeredith to try this out when it is ready for a review for 1.1.1 or 1.2 - he is most keen to ensure this is nice and smooth. 

          Michael Neale added a comment - kzantow please do enlist imeredith to try this out when it is ready for a review for 1.1.1 or 1.2 - he is most keen to ensure this is nice and smooth. 

          Karl Shultz added a comment -

          Testing Notes:
          It looks like this got fixed via this commit, which includes tests.

          Karl Shultz added a comment - Testing Notes: It looks like this got fixed via this commit , which includes tests.

            kzantow Keith Zantow
            michaelneale Michael Neale
            Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

              Created:
              Updated:
              Resolved: