I want to provide the pat-leaflet pattern including all it's dependencies for Plone 5 in plone.formwidget.geolocation ( https://github.com/patternslib/pat-leaflet ).
It doesn't feel quite right to configure and provide the resouces in plone.formwidget.geolocation, as some other packages might want to use it without plone.formwidget.geolocation. The registry configuration is quite comprehensive.
I'm thinking of creating a ploneresources.pat-leaflet package. In my opinion it makes more sense to create a new namespace for resource packages than to reuse the plone.* namespace for this.
However, this feels a bit awkward because back in the times when mockup was born, we discussed to get rid of the need of repackaging libraries like we did for collective.js.* or js.*/fanstatic? Now it looks like as if we need to repackage libraries again, if we don't want to repeat ourselves.
Maybe it's not too bad to worry about. At least bower helps with managing dependencies.
Any opinions or ideas, how to solve the original problem in a better way?
The frontend world moves at a different velocity than Plone. In Ploneintranet we do not include any patterns in our Plone packages. Instead, we compile a bundle outside of Plone and load only the compiled bundle. The bundle is kept outside of our git code repos, but is packaged and distributed as part of our egg releases.
Mockup gives us ready to use rich components, we can use in our templates and add-ons
resource registry gives us a less compiler, requireJS to load the existing JS in the right order inside a bundle (works only inside a bundle), minified JS and CSS bundles
But what we need, is a way to let add-ons rely on JS resources and we don't want solve that with python packages which provide them. So the best would be something like require some js package (from npm) in a Python Package which depends on that and use npm on install time to install that locally on the system when buildout runs. This will give us a version in the file system which we can pick up with browserify or webpack.
So a Python should provide a list of js packages probably in a package.js and should use npm in the setup.py to install this dependencies in a node_modules folder in the buildout directory. This node_modules directory could then be used by webpack & co to include this files in the browser where needed.
I'm not sure where the resource registry should fit in or if that would make it obsolete.
Any thoughts, ideas?
Still we need a solution about other libraries. I also think on having nodeJS as a dependency of Plone could make the resource registry obsolete. Which wouldn't be the worst thing, in my opinion. Although the resource registry really works surprisingly well despite it's complexity and dependency on API compliance with r.js and less.js. It's really genius, although I would have personally never done it that way.
I'm not sure about webpack. Isn't that also being deprecated? At least with http2 it will loose some of it's benefits.
Regarding npm (which webpack uses?) vs bower - in many cases npm again repackages libraries - at least for the use case we're talking about. Bower does not. Installing libraries, which were repackaged by some random guy via npm for no reason sounds again not right for me. I prefer using direct source checkouts via bower.
@thet How about putting the configuration into plone.formwidget.geolocation, but just not register it by default? For example, add it into a default profile of a sub-package of plone.formwidget.geolocation (like plone.formwidget.geolocation.pat-leaflet).
About webpack vs. bower vs. npm vs. registries:
Also npm can install directly from repositories. No packaging into npm.js required. Recently, I've been adding package.json into our in-house python packages to make them npm installable into our webpack build themes.
Yet, our registries are great, because they are independent from the continously changing JS tools (yet compatible, because we selected to base them on r.js).
With @sneridagh and @tisto we've been planning to refactor my webpack configuration to use Plone resource registries directly to easily get all the resources packaged with Plone and add-ons also into webpack (without need for finding those for npm). We'll be sprinting (remotely) as soon as @sneridagh has a suitable project and time for it.