Flexmonster deployment via gulp build

Update: I have realised that there is a flexmonster.full.js file, which I assume is the full bundled version, but I don't seem to be able to import flexmonster through requireJS from this file  - whenever the module is imported requirejs throws an error - "Mismatched anonymous define() module" for html2canvas and jspdf libraries. It would be great to be able to use this full bundled version, do you have some advice on how we can use this with requirejs?
 
Kind Regards,
 
Yousif

Thanks Tanya.
 
Just to add, I think there is a related issue with regards to the way flexmonster loads its dependencies, even when not using flexmonster.full - We already use d3 v4 in our app for other visualisations and also have other third-party libraries which depend on d3 v4, but when you switch to charts flexmonster loads its own version of d3 (v3), which causes the same requireJS error. This error is fatal for us, since our app is very modular and requireJS then fails to load any more modules

Hi Ian, 
 
Thanks for getting back to me and for providing the above samples. Unfortunately, using the latest version of flexmonster (2.7.3), I am now no longer able to instantiate a flexmonster instance at all - a TypeError is thrown "Flexmonster is not a constructor".
This is a different mechanism to v2.6.14, when the pivot was instantiated through jquery. I can see that some changes have been made to the typescript definitions in @types, but I cannot get this to work correctly with requireJS. We are not using Webpack in our project - I think in our case the issue is not RequireJS/Webpack, but rather integration with RequireJS/Typescript. 
I have created a sample project based on yours to illustrate the problem we are seeing. It also demostrates how we are using typescript and requireJS to load modules in our project: https://github.com/BV-YAhmed/PivotTestApp
 
With regards to d3, html2canvs and jspdf, I cannot confirm if these are now loading correctly since we can't get past this initial TypeError.
 
Any help/advice you can offer would be greatly appreciated - at present, we cannot use v2.7.3 at all!
 
Kind Regards,
 
Yousif

Hi Ian,
 thanks for providing the working sample, and apologies for the delay in getting back to you. I have spent a lot of time investigating this issue and would like to share my findings with you:
The sample you provided does in fact fix the AMD module definition, and we are able to compile and isntantiate flexmonster in Typescript with RequireJS. However, the bundled flexmonster.full is still incompatible with requireJS as its dependencies are not loaded properly through requireJS. This is evident in the working sample app - if you try to export to image or pdf, you will see an error in the console - 'html2canvas/jsPDF is not defined'.
I have spent some time investigating what is happening and I believe it is primarily down to the bundled dependencies 'html2canvas' and 'jsPDF':

• html2canvas calls define anonymously, and this is what causes the requireJS error, as the optimizer must have named modules only
• html2canvas is also bundled with jsPDF.min, so the module gets loaded twice, once by flexmonster and once by jsPDF.min. So even if html2canvas.min is edited the anonymous define() call still occurs from within jsPDF.min
• Flexmonster ships with an old version of jsPDF that also includes html2canvas as an internal bundled dependency (this has been addressed in later releases of jsPDF - see https://github.com/MrRio/jsPDF/releases/tag/v1.5.0)

I have only managed to work around the issue by taking the following steps:

1. Using the unbundled flexmonster.js file instead of flexmonster.full
2. Manually loading html2canvas into the global scope before loading flexmonster - this stops html2canvas from making the anonymous define() call
3. Installing the latest version of jsPDF from npm (which no longer includes html2canvas ) and loading this into the global scope before loading flexmonster

This solution works, but is far from ideal for a number of reasons:

1. I am using jsPDF v1.5.0, which seems to work fine with flexmonster 2.7.3, but this may not be the case for future versions of flexmonster
2. When using flexmonster instead of flexmonster.full, flexmonster still tries to load these libraries from componentFolder/lib/ even when they are present in the global scope, and if the files are not there the feature
   doesn't work. This means we will have to deploy a componentFolder/lib/ in production that contains duplicate copies of these components in order for these features to work. It would be great if flexmonster
   could check if these dependencies were already loaded before going to the lib/ folder?
3. I am not sure which other bundled dependencies exhibit the same problem - after implementing a workaround for jsPDF and html2canvas the export features seem to work properly but I have not done any extensive testing with the other bundled dependencies

 
It appears as though some of these issues are down to 3rd party libraries which are obviously beyond your control, but I think that if Flexmonster updated its dependencies and checked if they were already loaded before using them, this would probably go some way towards fixing the problem. When I get a chance I will make my workaround available to give you a better understanding of what is going on, but i have not had the chance to do this yet.
Kind Regards,
 
Yousif

Hi Ian,
Thank you for the revised version - I can confirm that this has resolved the issue for us, which is great. We are now able to use the bundled flexmonster.full successfully with Typescript and RequireJS, and both the exports and charts features are working properly. 

There is still an issue with the file when we run the requireJS optimizer (r.js) during our production build - this is what combines and uglifies all of our scripts/modules into one file. The optimizer throws an error when trying to parse the flexmonster.full file - "Cannot read property 'type' of undefined". However this is not a big problem, we're able to work around this by just excluding flexmonster from this optimisation.

Again, thanks for your help with this as we would not have been able to use the control without the improvements you have made.
 
Kind Regards,
 
Yousif