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

Improving developer experience for blue ocean core developers and extenders

    • Icon: Epic Epic
    • Resolution: Unresolved
    • Icon: Minor Minor
    • blueocean-plugin
    • None
    • Developer Experience

      The dev process around Blue Ocean and the hoops we have to jump through wrt NPM packages is both painful and confusing - too easy to screw things up or forget to do something (publish a package etc). Shrinkwrap (aka "Shrinkcrap") is wrecking everyone's head.

      We need to improve the tools (and maybe create new tools) to help smooth and speed the process here. Maybe we should create an Epic for this and break out multiple JIRAs.

      Anyway ... this might be my scunkworks project for when I'm bored during my vacation time over the next few weeks.

          [JENKINS-40392] Improving developer experience for blue ocean core developers and extenders

          Michael Neale added a comment - - edited

          Some of those tickets seem a little too "prescriptive" (ie leaping to the solution).

          I think there needs to be some problem statements of things that should be solved (otherwise this is just moving aroubd pieces for no point). Off the top of my head:

          1) A developer should easily be able to update a shared js dependency during development that is used across a multi module project without messing with package.json files and versions
          2) A developer should be able to open a pull request for review without having to publish beta versions of shared js libs (related to #1)
          3) A developer shouldn't need to worry about updating shrinkwrap
          4) Clean build speed should be faster, or changing branches should not require a full clean
          5) A developer shouldn't have to worry about where watch is run, changes should be picked up automatically during hpi:run
          6) A developer should be able to easily "link" in a js lib that is outside the blueocean-plugin dir at development time to make co-ordinated changes.
          7) A plugin developer shouldn't worry about matching versions with what blueocean-web/dashboard requires, but just depend on blueocean (for plugins outside of the blueocean-plugin dir)
          8) A plugin developer should not worry about inadvertently bundling a dependency which blueocean should deliver

          Michael Neale added a comment - - edited Some of those tickets seem a little too "prescriptive" (ie leaping to the solution). I think there needs to be some problem statements of things that should be solved (otherwise this is just moving aroubd pieces for no point). Off the top of my head: 1) A developer should easily be able to update a shared js dependency during development that is used across a multi module project without messing with package.json files and versions 2) A developer should be able to open a pull request for review without having to publish beta versions of shared js libs (related to #1) 3) A developer shouldn't need to worry about updating shrinkwrap 4) Clean build speed should be faster, or changing branches should not require a full clean 5) A developer shouldn't have to worry about where watch is run, changes should be picked up automatically during hpi:run 6) A developer should be able to easily "link" in a js lib that is outside the blueocean-plugin dir at development time to make co-ordinated changes. 7) A plugin developer shouldn't worry about matching versions with what blueocean-web/dashboard requires, but just depend on blueocean (for plugins outside of the blueocean-plugin dir) 8) A plugin developer should not worry about inadvertently bundling a dependency which blueocean should deliver

          Tom FENNELLY added a comment -

          Yeah, might be in some cases. I've tried to mark any solutioneering with something like "Possible Solution", or the like.

          Tom FENNELLY added a comment - Yeah, might be in some cases. I've tried to mark any solutioneering with something like "Possible Solution", or the like.

            tfennelly Tom FENNELLY
            michaelneale Michael Neale
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

              Created:
              Updated: