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

Properly generate bundles for packages that have multiple top-level modules

    XMLWordPrintable

Details

    • Blue Ocean 1.2-beta2

    Description

      Bundled are generated in a sub optimal way. One side effect is there could be multiple submodules of popular libraries appearing in different bundles. 


      See this doc for a description of the problem(s).

      Attachments

        Issue Links

          Activity

            tfennelly Tom FENNELLY created issue -
            tfennelly Tom FENNELLY made changes -
            Field Original Value New Value
            Epic Link JENKINS-37957 [ 174099 ]
            tfennelly Tom FENNELLY made changes -
            Link This issue is related to JENKINS-38013 [ JENKINS-38013 ]
            tfennelly Tom FENNELLY made changes -
            Link This issue depends on JENKINS-39657 [ JENKINS-39657 ]
            tfennelly Tom FENNELLY made changes -
            Description We fixed some bundling issues last week ... non bootstrap bundles (dashboard etc) are now back down to somewhat reasonable sizes (they were at ~ 2Mb in some cases), but the blueocean.js bootstrp bundle is still at about 3Mb because we have the kitchen sink thrown in there. If it's going to be that huge (something we did not know earlier in the game), then we need to tweak how we are doing the bundling.

            I've been working on this off-and-on over the last week or two. I've made progress on it (blueocean.js now at abou 0.6Mb), but have run into other react pita issues now (react == "pain" for me :) ). I've not been able to figure that issue out and I think I'm going to need to build some more tooling for myself in order to do that (will also hopefully help when we hit the next react/other bundling issue).

            So, parking this issue for now and we will come back to it later. Relevant WIP:

            * https://github.com/tfennelly/jenkins-js-builder/tree/all-extern-bundles
            * https://github.com/tfennelly/blueocean-plugin/tree/all-extern-bundles
            We fixed some bundling issues last week ... non bootstrap bundles (dashboard etc) are now back down to somewhat reasonable sizes (they were at ~ 2Mb in some cases), but the blueocean.js bootstrp bundle is still at about 3Mb because we have the kitchen sink thrown in there. If it's going to be that huge (something we did not know earlier in the game), then we need to tweak how we are doing the bundling.

            I've been working on this off-and-on over the last week or two. I've made progress on it (blueocean.js now at abou 0.6Mb), but have run into other react pita issues now (react == "pain" for me :) ). I've not been able to figure that issue out and I think I'm going to need to build some more tooling for myself in order to do that (will also hopefully help when we hit the next react/other bundling issue) - see JENKINS-39657.

            So, parking this issue for now and we will come back to it later. Relevant WIP:

            * https://github.com/tfennelly/jenkins-js-builder/tree/all-extern-bundles
            * https://github.com/tfennelly/blueocean-plugin/tree/all-extern-bundles
            tfennelly Tom FENNELLY made changes -
            Component/s js-builder [ 21132 ]
            Component/s js-modules [ 21133 ]
            tfennelly Tom FENNELLY made changes -
            Summary Extract more dependencies out into their own JS bundles Properly generate bundles for packages that have multiple top-level modules
            tfennelly Tom FENNELLY made changes -
            Issue Type Task [ 3 ] Bug [ 1 ]
            tfennelly Tom FENNELLY made changes -
            Epic Link JENKINS-37957 [ 174099 ] JENKINS-35749 [ 171790 ]
            tfennelly Tom FENNELLY made changes -
            Priority Major [ 3 ] Blocker [ 1 ]
            tfennelly Tom FENNELLY added a comment -

            This work MUST be done before we do anything in Blue Ocean 1.0+. Please DO NOT change the priority of this task.

            tfennelly Tom FENNELLY added a comment - This work MUST be done before we do anything in Blue Ocean 1.0+. Please DO NOT change the priority of this task.
            tfennelly Tom FENNELLY added a comment -

            However, we need some browser tooling in order to do this properly (see JENKINS-39657). We need to be able to reliably analyse across all bundles in the browser at runtime. ATM, I do this manually by opening the bundles and looking in them visually. I also created a CLI tool called browserify-tree that does help a lot, but again, it only allows me to analyse a single bundle.

            tfennelly Tom FENNELLY added a comment - However, we need some browser tooling in order to do this properly (see JENKINS-39657 ). We need to be able to reliably analyse across all bundles in the browser at runtime. ATM, I do this manually by opening the bundles and looking in them visually. I also created a CLI tool called browserify-tree that does help a lot, but again, it only allows me to analyse a single bundle.
            tfennelly Tom FENNELLY made changes -
            Description We fixed some bundling issues last week ... non bootstrap bundles (dashboard etc) are now back down to somewhat reasonable sizes (they were at ~ 2Mb in some cases), but the blueocean.js bootstrp bundle is still at about 3Mb because we have the kitchen sink thrown in there. If it's going to be that huge (something we did not know earlier in the game), then we need to tweak how we are doing the bundling.

            I've been working on this off-and-on over the last week or two. I've made progress on it (blueocean.js now at abou 0.6Mb), but have run into other react pita issues now (react == "pain" for me :) ). I've not been able to figure that issue out and I think I'm going to need to build some more tooling for myself in order to do that (will also hopefully help when we hit the next react/other bundling issue) - see JENKINS-39657.

            So, parking this issue for now and we will come back to it later. Relevant WIP:

            * https://github.com/tfennelly/jenkins-js-builder/tree/all-extern-bundles
            * https://github.com/tfennelly/blueocean-plugin/tree/all-extern-bundles
            js-modules, js-builder etc were written based on some assumptions (pre Blue Ocean). The main one that's relevant to this task was the assumption that dependency packages are always accessed via a single top-level/entry/main module and that that modules would be the bundle entry-point module.

            Of course in reality that's not how some NPM packages are created. Some of them contain multiple top-level/entry modules. React is the one most relevant to Blue Ocean ... it has lots of top level modules, so much so that lots of secondary/child NPM packages have sprung up in the react eco system that do nothing more than define an NPM "main" module entry point for a module inside the react package e.g. some of the ones we use in Blue Ocean ... "react-dom", "react-addons-css-transition-group", "react-addons-test-utils".

            We need to change how our bundling works so that we can properly accommodate this reality, generating dependency bundles are guaranteed to contain all the package modules needed so that all entry-modules are covered/supported by the bundle. Likewise, when generating bundles that depend on these packages, we need to make sure that the externalized/shared bundle is always wired in properly and that no external dep modules "leak" in through the back door.

            I've been working on this off-and-on over the last week or two. I've made progress on it (blueocean.js now at abou 0.6Mb), but have run into other react pita issues now (react == "pain" for me :) ). I've not been able to figure that issue out and I think I'm going to need to build some more tooling for myself in order to do that (will also hopefully help when we hit the next react/other bundling issue) - see JENKINS-39657.

            So, parking this issue for now and we will come back to it later. Relevant WIP:

            * https://github.com/tfennelly/jenkins-js-builder/tree/all-extern-bundles
            * https://github.com/tfennelly/blueocean-plugin/tree/all-extern-bundles
            tfennelly Tom FENNELLY made changes -
            Description js-modules, js-builder etc were written based on some assumptions (pre Blue Ocean). The main one that's relevant to this task was the assumption that dependency packages are always accessed via a single top-level/entry/main module and that that modules would be the bundle entry-point module.

            Of course in reality that's not how some NPM packages are created. Some of them contain multiple top-level/entry modules. React is the one most relevant to Blue Ocean ... it has lots of top level modules, so much so that lots of secondary/child NPM packages have sprung up in the react eco system that do nothing more than define an NPM "main" module entry point for a module inside the react package e.g. some of the ones we use in Blue Ocean ... "react-dom", "react-addons-css-transition-group", "react-addons-test-utils".

            We need to change how our bundling works so that we can properly accommodate this reality, generating dependency bundles are guaranteed to contain all the package modules needed so that all entry-modules are covered/supported by the bundle. Likewise, when generating bundles that depend on these packages, we need to make sure that the externalized/shared bundle is always wired in properly and that no external dep modules "leak" in through the back door.

            I've been working on this off-and-on over the last week or two. I've made progress on it (blueocean.js now at abou 0.6Mb), but have run into other react pita issues now (react == "pain" for me :) ). I've not been able to figure that issue out and I think I'm going to need to build some more tooling for myself in order to do that (will also hopefully help when we hit the next react/other bundling issue) - see JENKINS-39657.

            So, parking this issue for now and we will come back to it later. Relevant WIP:

            * https://github.com/tfennelly/jenkins-js-builder/tree/all-extern-bundles
            * https://github.com/tfennelly/blueocean-plugin/tree/all-extern-bundles
            js-modules, js-builder etc were written based on some assumptions (pre Blue Ocean). The main one that's relevant to this task was the assumption that dependency packages are always accessed via a single top-level/entry/main module and that that modules would be the bundle entry-point module.

            Of course in reality that's not how some NPM packages are created. Some of them contain multiple top-level/entry modules. React is the one most relevant to Blue Ocean ... it has lots of top level modules, so much so that lots of secondary/child NPM packages have sprung up in the react eco system that do nothing more than define an NPM "main" module entry point for a module inside the react package e.g. some of the ones we use in Blue Ocean ... "react-dom", "react-addons-css-transition-group", "react-addons-test-utils".

            We need to change how our bundling works so that we can properly accommodate this reality, generating dependency bundles that are guaranteed to contain all the package modules needed so that all entry-modules are covered/supported by the bundle. Likewise, when generating bundles that depend on these packages, we need to make sure that the externalized/shared bundle is always wired in properly and that no external dep modules "leak" in through the back door.

            I've been working on this off-and-on over the last week or two. I've made progress on it (blueocean.js now at abou 0.6Mb), but have run into other react pita issues now (react == "pain" for me :) ). I've not been able to figure that issue out and I think I'm going to need to build some more tooling for myself in order to do that (will also hopefully help when we hit the next react/other bundling issue) - see JENKINS-39657.

            So, parking this issue for now and we will come back to it later. Relevant WIP:

            * https://github.com/tfennelly/jenkins-js-builder/tree/all-extern-bundles
            * https://github.com/tfennelly/blueocean-plugin/tree/all-extern-bundles
            tfennelly Tom FENNELLY added a comment - - edited

            There's also another related scenario that needs to be covered here, which is when one or more different versions of a package to be externalized end up in the node_modules of package in node_modules (i.e. npm trying to handle conflicting versions of the package) e.g. /node_modules/@jenkins-cd/blueocean-core-js/node_modules/react/react.js because @jenkins-cd/blueocean-core-js depends on a specific version of react that is not the same as the top level installed version of react ( in /node_modules/react ).

            tfennelly Tom FENNELLY added a comment - - edited There's also another related scenario that needs to be covered here, which is when one or more different versions of a package to be externalized end up in the node_modules of package in node_modules (i.e. npm trying to handle conflicting versions of the package) e.g. /node_modules/@jenkins-cd/blueocean-core-js/node_modules/react/react.js because @jenkins-cd/blueocean-core-js depends on a specific version of react that is not the same as the top level installed version of react ( in /node_modules/react ).
            michaelneale Michael Neale added a comment -

            hey tfennelly any news on this and the dependent ticket for chrome tools (given priority of this)?

            michaelneale Michael Neale added a comment - hey tfennelly any news on this and the dependent ticket for chrome tools (given priority of this)?
            tfennelly Tom FENNELLY added a comment -

            Some progress made on JENKINS-39657 alright (basic chrome extension created - there was a bit of learning needed on these extensions), but can't effectively do anything on this ticket without first getting JENKINS-39657 to a stage where it can answer the kinds of questions I need it to help give answers to. I think I'm a couple of days awaf from that yet - guessing 2 or 3. This stuff is not going to be done for 1.0, but I'm guessing you already know that.

            I've been away for the last week and it's Paddy's day here today and I'm jetlagged

            tfennelly Tom FENNELLY added a comment - Some progress made on JENKINS-39657 alright ( basic chrome extension created - there was a bit of learning needed on these extensions), but can't effectively do anything on this ticket without first getting JENKINS-39657 to a stage where it can answer the kinds of questions I need it to help give answers to. I think I'm a couple of days awaf from that yet - guessing 2 or 3. This stuff is not going to be done for 1.0, but I'm guessing you already know that. I've been away for the last week and it's Paddy's day here today and I'm jetlagged
            michaelneale Michael Neale added a comment -

            tfennelly yeah no worries - happy st pats! I assumed that https://issues.jenkins-ci.org/browse/JENKINS-39657 was the blocking thing still, not sure why I commented here. 

            michaelneale Michael Neale added a comment - tfennelly yeah no worries - happy st pats! I assumed that https://issues.jenkins-ci.org/browse/JENKINS-39657  was the blocking thing still, not sure why I commented here. 
            jamesdumay James Dumay made changes -
            Priority Blocker [ 1 ] Major [ 3 ]
            jamesdumay James Dumay made changes -
            Labels technical-debt
            jamesdumay James Dumay made changes -
            Epic Link JENKINS-35749 [ 171790 ] JENKINS-35756 [ 171764 ]
            michaelneale Michael Neale made changes -
            Description js-modules, js-builder etc were written based on some assumptions (pre Blue Ocean). The main one that's relevant to this task was the assumption that dependency packages are always accessed via a single top-level/entry/main module and that that modules would be the bundle entry-point module.

            Of course in reality that's not how some NPM packages are created. Some of them contain multiple top-level/entry modules. React is the one most relevant to Blue Ocean ... it has lots of top level modules, so much so that lots of secondary/child NPM packages have sprung up in the react eco system that do nothing more than define an NPM "main" module entry point for a module inside the react package e.g. some of the ones we use in Blue Ocean ... "react-dom", "react-addons-css-transition-group", "react-addons-test-utils".

            We need to change how our bundling works so that we can properly accommodate this reality, generating dependency bundles that are guaranteed to contain all the package modules needed so that all entry-modules are covered/supported by the bundle. Likewise, when generating bundles that depend on these packages, we need to make sure that the externalized/shared bundle is always wired in properly and that no external dep modules "leak" in through the back door.

            I've been working on this off-and-on over the last week or two. I've made progress on it (blueocean.js now at abou 0.6Mb), but have run into other react pita issues now (react == "pain" for me :) ). I've not been able to figure that issue out and I think I'm going to need to build some more tooling for myself in order to do that (will also hopefully help when we hit the next react/other bundling issue) - see JENKINS-39657.

            So, parking this issue for now and we will come back to it later. Relevant WIP:

            * https://github.com/tfennelly/jenkins-js-builder/tree/all-extern-bundles
            * https://github.com/tfennelly/blueocean-plugin/tree/all-extern-bundles
            js-modules, js-builder etc were written based on some assumptions (pre Blue Ocean). The main one that's relevant to this task was the assumption that dependency packages are always accessed via a single top-level/entry/main module and that that modules would be the bundle entry-point module.

            Of course in reality that's not how some NPM packages are created. Some of them contain multiple top-level/entry modules. React is the one most relevant to Blue Ocean ... it has lots of top level modules, so much so that lots of secondary/child NPM packages have sprung up in the react eco system that do nothing more than define an NPM "main" module entry point for a module inside the react package e.g. some of the ones we use in Blue Ocean ... "react-dom", "react-addons-css-transition-group", "react-addons-test-utils".

            We need to change how our bundling works so that we can properly accommodate this reality, generating dependency bundles that are guaranteed to contain all the package modules needed so that all entry-modules are covered/supported by the bundle. Likewise, when generating bundles that depend on these packages, we need to make sure that the externalized/shared bundle is always wired in properly and that no external dep modules "leak" in through the back door.

            I've been working on this off-and-on over the last week or two. I've made progress on it (blueocean.js now at abou 0.6Mb), but have run into other react pita issues now (react == "pain" for me :) ). I've not been able to figure that issue out and I think I'm going to need to build some more tooling for myself in order to do that (will also hopefully help when we hit the next react/other bundling issue) - see -JENKINS-39657-.

            So, parking this issue for now and we will come back to it later. Relevant WIP:
             * [https://github.com/tfennelly/jenkins-js-builder/tree/all-extern-bundles]
             * [https://github.com/tfennelly/blueocean-plugin/tree/all-extern-bundles]

             

            Those branches are way out of date now, but from memory, one of the main issues that needs to be solved (and which I take a stab at in those PRs) is the idea of generating a "complete" bundles (deterministically including all modules from a package e.g. react Vs just the modules that are on the entry module's graph) and changing the module loading such that it can load any module from a bundle (and not just the entry module).
            tfennelly Tom FENNELLY made changes -
            Priority Major [ 3 ] Critical [ 2 ]
            tfennelly Tom FENNELLY made changes -
            Attachment screenshot-1.png [ 38658 ]
            tfennelly Tom FENNELLY added a comment -

            As stated in the very first comment on this ticket ... Please DO NOT change the priority of this ticket.

            I appreciate that things might "seem ok", but imo this issue is a bit more than "technical debt" i.e. it's a fundamental issue with how we are generating bundles and is destined to be a serious issue, especially once we have multiple versions of Blue Ocean out in the wild, with JS bundles generated with different NPM package versions etc.

            It's been a job getting people to take me seriously on this one (e.g. downgrading the priority). Maybe install jenkins-js-modules-chrome-ext in your Chrome browser, open a Blue Ocean instance and take a look at the number of errors and warnings. These are pretty much all relating to this bug in the bundle generation.

            Also ... the bundles are "fatter" than they need to be because of this.

            As an example from https://ci.blueocean.io (140+ errors detected in dashboard and personalization bundles) ...

            tfennelly Tom FENNELLY added a comment - As stated in the very first comment on this ticket ... Please DO NOT change the priority of this ticket. I appreciate that things might "seem ok", but imo this issue is a bit more than "technical debt" i.e. it's a fundamental issue with how we are generating bundles and is destined to be a serious issue, especially once we have multiple versions of Blue Ocean out in the wild, with JS bundles generated with different NPM package versions etc. It's been a job getting people to take me seriously on this one (e.g. downgrading the priority). Maybe install jenkins-js-modules-chrome-ext in your Chrome browser, open a Blue Ocean instance and take a look at the number of errors and warnings. These are pretty much all relating to this bug in the bundle generation. Also ... the bundles are "fatter" than they need to be because of this. As an example from https://ci.blueocean.io (140+ errors detected in dashboard and personalization bundles) ...
            michaelneale Michael Neale made changes -
            Sprint Blue Ocean 1.2-beta2 [ 341 ]
            michaelneale Michael Neale made changes -
            Assignee Tom FENNELLY [ tfennelly ]
            michaelneale Michael Neale added a comment -

            Bringing this up for discussion at next hangout.. 

            michaelneale Michael Neale added a comment - Bringing this up for discussion at next hangout.. 
            jamesdumay James Dumay made changes -
            Sprint Blue Ocean 1.2-beta2 [ 341 ] Blue Ocean 1.2-beta2, Blue Ocean 1.2-beta3 [ 341, 346 ]
            jamesdumay James Dumay added a comment -

            michaelneale still needed on the board?

            jamesdumay James Dumay added a comment - michaelneale still needed on the board?
            jamesdumay James Dumay made changes -
            Sprint Blue Ocean 1.2-beta2, Blue Ocean 1.2-beta3 [ 341, 346 ] Blue Ocean 1.2-beta2 [ 341 ]
            jamesdumay James Dumay made changes -
            Sprint Blue Ocean 1.2-beta2 [ 341 ] Blue Ocean 1.2-beta2, Blue Ocean 1.2-beta4 [ 341, 361 ]
            jamesdumay James Dumay made changes -
            Rank Ranked higher
            jamesdumay James Dumay made changes -
            Priority Critical [ 2 ] Major [ 3 ]
            jamesdumay James Dumay made changes -
            Sprint Blue Ocean 1.2-beta2, Blue Ocean 1.2-beta4 [ 341, 361 ] Blue Ocean 1.3, Blue Ocean 1.2-beta2 [ 296, 341 ]
            jamesdumay James Dumay made changes -
            Rank Ranked lower
            tfennelly Tom FENNELLY added a comment -

            I'm going to write up a more detailed and structured doc around all of this wrt what's wrong today with how we generate an use bundles and what I think we need to do to put it right (or more right than it is).

            There are a few fundamental things we are doing wrong imo (yes, my fault). I'd really like to put those things right before we try doing things like what's in jenkinsci/js-builder/pull/19. How we allow exports of modules today without properly generating a "dependency bundle" (e.g. how we export some modules in blueocean.js in the blueocean-web plugin) is fundamentally wrong and is eventually going to break badly ... just a matter of time!! jenkinsci/js-builder/pull/19 would very likely make that situation a lot worse imo + make it harder to fix. So, I'm firmly of the opinion that we fix how we generate bundles etc first, and then come back and see how we can make jenkinsci/js-builder/pull/19 work where it'll be on more solid foundations.

            tfennelly Tom FENNELLY added a comment - I'm going to write up a more detailed and structured doc around all of this wrt what's wrong today with how we generate an use bundles and what I think we need to do to put it right (or more right than it is). There are a few fundamental things we are doing wrong imo (yes, my fault). I'd really like to put those things right before we try doing things like what's in jenkinsci/js-builder/pull/19 . How we allow exports of modules today without properly generating a "dependency bundle" (e.g. how we export some modules in blueocean.js in the blueocean-web plugin) is fundamentally wrong and is eventually going to break badly ... just a matter of time!! jenkinsci/js-builder/pull/19 would very likely make that situation a lot worse imo + make it harder to fix. So, I'm firmly of the opinion that we fix how we generate bundles etc first, and then come back and see how we can make jenkinsci/js-builder/pull/19 work where it'll be on more solid foundations.
            jamesdumay James Dumay made changes -
            Sprint Blue Ocean 1.3-beta-2, Blue Ocean 1.2-beta2 [ 296, 341 ] Blue Ocean 1.4, Blue Ocean 1.2-beta2 [ 311, 341 ]
            jamesdumay James Dumay made changes -
            Rank Ranked higher
            michaelneale Michael Neale made changes -
            Description js-modules, js-builder etc were written based on some assumptions (pre Blue Ocean). The main one that's relevant to this task was the assumption that dependency packages are always accessed via a single top-level/entry/main module and that that modules would be the bundle entry-point module.

            Of course in reality that's not how some NPM packages are created. Some of them contain multiple top-level/entry modules. React is the one most relevant to Blue Ocean ... it has lots of top level modules, so much so that lots of secondary/child NPM packages have sprung up in the react eco system that do nothing more than define an NPM "main" module entry point for a module inside the react package e.g. some of the ones we use in Blue Ocean ... "react-dom", "react-addons-css-transition-group", "react-addons-test-utils".

            We need to change how our bundling works so that we can properly accommodate this reality, generating dependency bundles that are guaranteed to contain all the package modules needed so that all entry-modules are covered/supported by the bundle. Likewise, when generating bundles that depend on these packages, we need to make sure that the externalized/shared bundle is always wired in properly and that no external dep modules "leak" in through the back door.

            I've been working on this off-and-on over the last week or two. I've made progress on it (blueocean.js now at abou 0.6Mb), but have run into other react pita issues now (react == "pain" for me :) ). I've not been able to figure that issue out and I think I'm going to need to build some more tooling for myself in order to do that (will also hopefully help when we hit the next react/other bundling issue) - see -JENKINS-39657-.

            So, parking this issue for now and we will come back to it later. Relevant WIP:
             * [https://github.com/tfennelly/jenkins-js-builder/tree/all-extern-bundles]
             * [https://github.com/tfennelly/blueocean-plugin/tree/all-extern-bundles]

             

            Those branches are way out of date now, but from memory, one of the main issues that needs to be solved (and which I take a stab at in those PRs) is the idea of generating a "complete" bundles (deterministically including all modules from a package e.g. react Vs just the modules that are on the entry module's graph) and changing the module loading such that it can load any module from a bundle (and not just the entry module).
            Bundled are generated in a sub optimal way. One side effect is there could be multiple submodules of popular libraries appearing in different bundles. 

            ----

            js-modules, js-builder etc were written based on some assumptions (pre Blue Ocean). The main one that's relevant to this task was the assumption that dependency packages are always accessed via a single top-level/entry/main module and that that modules would be the bundle entry-point module.

            Of course in reality that's not how some NPM packages are created. Some of them contain multiple top-level/entry modules. React is the one most relevant to Blue Ocean ... it has lots of top level modules, so much so that lots of secondary/child NPM packages have sprung up in the react eco system that do nothing more than define an NPM "main" module entry point for a module inside the react package e.g. some of the ones we use in Blue Ocean ... "react-dom", "react-addons-css-transition-group", "react-addons-test-utils".

            We need to change how our bundling works so that we can properly accommodate this reality, generating dependency bundles that are guaranteed to contain all the package modules needed so that all entry-modules are covered/supported by the bundle. Likewise, when generating bundles that depend on these packages, we need to make sure that the externalized/shared bundle is always wired in properly and that no external dep modules "leak" in through the back door.

            I've been working on this off-and-on over the last week or two. I've made progress on it (blueocean.js now at abou 0.6Mb), but have run into other react pita issues now (react == "pain" for me :) ). I've not been able to figure that issue out and I think I'm going to need to build some more tooling for myself in order to do that (will also hopefully help when we hit the next react/other bundling issue) - see --JENKINS-39657--.

            So, parking this issue for now and we will come back to it later. Relevant WIP:
             * [https://github.com/tfennelly/jenkins-js-builder/tree/all-extern-bundles]
             * [https://github.com/tfennelly/blueocean-plugin/tree/all-extern-bundles]

             

            Those branches are way out of date now, but from memory, one of the main issues that needs to be solved (and which I take a stab at in those PRs) is the idea of generating a "complete" bundles (deterministically including all modules from a package e.g. react Vs just the modules that are on the entry module's graph) and changing the module loading such that it can load any module from a bundle (and not just the entry module).
            tfennelly Tom FENNELLY made changes -
            Description Bundled are generated in a sub optimal way. One side effect is there could be multiple submodules of popular libraries appearing in different bundles. 

            ----

            js-modules, js-builder etc were written based on some assumptions (pre Blue Ocean). The main one that's relevant to this task was the assumption that dependency packages are always accessed via a single top-level/entry/main module and that that modules would be the bundle entry-point module.

            Of course in reality that's not how some NPM packages are created. Some of them contain multiple top-level/entry modules. React is the one most relevant to Blue Ocean ... it has lots of top level modules, so much so that lots of secondary/child NPM packages have sprung up in the react eco system that do nothing more than define an NPM "main" module entry point for a module inside the react package e.g. some of the ones we use in Blue Ocean ... "react-dom", "react-addons-css-transition-group", "react-addons-test-utils".

            We need to change how our bundling works so that we can properly accommodate this reality, generating dependency bundles that are guaranteed to contain all the package modules needed so that all entry-modules are covered/supported by the bundle. Likewise, when generating bundles that depend on these packages, we need to make sure that the externalized/shared bundle is always wired in properly and that no external dep modules "leak" in through the back door.

            I've been working on this off-and-on over the last week or two. I've made progress on it (blueocean.js now at abou 0.6Mb), but have run into other react pita issues now (react == "pain" for me :) ). I've not been able to figure that issue out and I think I'm going to need to build some more tooling for myself in order to do that (will also hopefully help when we hit the next react/other bundling issue) - see --JENKINS-39657--.

            So, parking this issue for now and we will come back to it later. Relevant WIP:
             * [https://github.com/tfennelly/jenkins-js-builder/tree/all-extern-bundles]
             * [https://github.com/tfennelly/blueocean-plugin/tree/all-extern-bundles]

             

            Those branches are way out of date now, but from memory, one of the main issues that needs to be solved (and which I take a stab at in those PRs) is the idea of generating a "complete" bundles (deterministically including all modules from a package e.g. react Vs just the modules that are on the entry module's graph) and changing the module loading such that it can load any module from a bundle (and not just the entry module).
            Bundled are generated in a sub optimal way. One side effect is there could be multiple submodules of popular libraries appearing in different bundles. 

            ----

            [See this doc for a description of the problem(s)|https://docs.google.com/document/d/1HPeK1W9UtHAGGmjnrBTIjmb7gs8HEYgJ5KtSxOkc9tY/edit?usp=sharing].
            tfennelly Tom FENNELLY added a comment -

            I added the doc. It's linked to in the main description.

            tfennelly Tom FENNELLY added a comment - I added the doc. It's linked to in the main description.
            jamesdumay James Dumay made changes -
            Sprint Blue Ocean 1.5 - candidates, Blue Ocean 1.2-beta2 [ 311, 341 ] Blue Ocean 1.2-beta2 [ 341 ]
            jamesdumay James Dumay made changes -
            Rank Ranked higher
            tfennelly Tom FENNELLY added a comment -

            jamesdumay I think we can close this a "Won't Do" .

            tfennelly Tom FENNELLY added a comment - jamesdumay I think we can close this a "Won't Do" .
            jamesdumay James Dumay made changes -
            Resolution Won't Fix [ 2 ]
            Status Open [ 1 ] Resolved [ 5 ]
            tscherler Thorsten Scherler made changes -
            Link This issue blocks JENKINS-47673 [ JENKINS-47673 ]
            tscherler Thorsten Scherler made changes -
            Link This issue relates to JENKINS-47673 [ JENKINS-47673 ]
            tscherler Thorsten Scherler made changes -
            Link This issue blocks JENKINS-47673 [ JENKINS-47673 ]
            jbriden Jenn Briden made changes -
            Status Resolved [ 5 ] Closed [ 6 ]

            People

              Unassigned Unassigned
              tfennelly Tom FENNELLY
              Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: