Ok, as someone just barely wrapping my head around the new ways JS resources are managed in Plone 5, I have a question...
I have a Plone 4 application that is using application JavaScript built/bundled with gulp+webpack+babeljs (from ECMAScript 6). As a stand-alone application, where I pre-build my entire, single JavaScript file, I can see a simple path for each of Plone 4 and Plone 5. But at some future point, how does this "build it all ahead of time" workflow play nice with AMD and Plone's new resource registry?
Suppose I want to depend on something shipped with Plone in my JS application built by webpack (or similar)?
I suspect I am missing something simple with regard to dependency management when some things are provided by the build process (webpack) but I also want to use a library shipped with Plone without shipping it again myself? I recognize this might well be more of a webpack problem [1] than a Plone problem.
Anybody using a webpack workflow with a Plone 5 project? Thoughts?
I would say that you need to register your app as a bundle in plone 5 that uses the resource that is a definition of a js. In your case the resource is already compiled if you don't wanna use require.js compilation throw the web.
All plone libraries in plone are wrapped on requirejs so if you wanna make sure that you have them you can require on the head of your app.
When you have your bundle registered you can add it to the script line with a add_bundle_in_request for the browserview that returns your app.
If you wanna not include some js libraries inside your webpack then you need to exclude on your gulp/webpack/babeljs configuration, as plone only understands about requirejs.
Yes !
It will be on docs.plone.org/5 as soon as I have finished the paster/mrbob story on Plone 4 docs, apparently we have way more references to paster than we thought and updating them costs lots time.
This is basically the last blocker before we publish a new release of the docs.
Currently, the external library support for AMD is not optimal. Some libs do, some don't, some do it the wrong way. We can cover all those, but it's a pain (e.g. I tried to integrate Leaflet with some of it's plugins, which is not easy).
Soon (say, in the next two years) ECMAScript 6 will be natively supported by all major browsers, libraries will adopt to it and remove AMD support and this will draw require.js obsolete.
I think we should keep this in mind.
However, our current investment in mockup with it's require.js based implementation is NOT like throwing money to a dead horse, because it's working quite well for us NOW.
But integrating web apps like the one described by @seanupton requires some unusal hacks, which will go away when we have to go into another JavaScript modernization round, but this time aligning mockup to actual JavaScript standards.