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

Improve publishing and sharing of pure JS modules/libraries

    Details

    • Similar Issues:
    • Epic Link:
    • Sprint:
      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

      Description

      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 Cliff Meyers Keith Zantow 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? 

        Attachments

          Issue Links

            Activity

            Hide
            cliffmeyers 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 Keith Zantow 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.

            Show
            cliffmeyers 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 Keith Zantow 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.
            Hide
            kzantow 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.

             

            Show
            kzantow 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.  
            Hide
            michaelneale 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).

            Show
            michaelneale 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).
            Hide
            michaelneale Michael Neale added a comment -

            Keith Zantow please do enlist Ivan Meredith 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. 

            Show
            michaelneale Michael Neale added a comment - Keith Zantow please do enlist Ivan Meredith 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. 
            Hide
            kshultz Karl Shultz added a comment -

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

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

              People

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

                Dates

                • Created:
                  Updated:
                  Resolved: