Mockup pattern template

[reinhardt]

This adds a new template mockup_pattern. It can be applied multiple times, resulting in multiple patterns in resources/patterns. All patterns are combined into a single bundle. For this purpose the pre_render() method keeps the existing imports if bundle.js already exists.

The paths are up for debate. Also, some of the dotfiles may not be needed. In general, suggestions for improvements are welcome.

I've manually tested the webpack and css build scripts, installed the addon and saw the compiled js bundle and css loaded in my instance.

Replaces #505

[MrTango]

Hi @reinhardt, thx for the PR. But I'm not sure i like the structure yet. So far itried to keep every aded feature close together and separate from other features added. Here we spread the files into different folders, which look to me as for the next pattern we would put more files in the same folders. I would like to keep every pattern isolated and as flat as possible directly in the top resource folder: what about this:

• resources
  • pat-example1
  • package.json
  • src
    • pat-example.js
    • pat-example.scss
  • pat-example2

Do we need to add these patterns to a registry file or are we deploying them as separate bundles via MF? I noticed that you are updating a JS file in the hook. If we don't need to update JavaScript files, the mockup_pattern.py get's simpler.

[MrTango]

ok, the updating of the js file probably makes sense, to not having to many bundles when creating a package with multiple pattrns. But the structure i would like to have a bit more flat as described. The idea was to also have the svelte apps landing in resources on the top level. But if we do that, we either have to integrate them into the one bundle as you do now or live with the extra patterns folder to separate them. I need to think about that a bit. But in any case it would be good when patterns are separated, so that they can be easiely published as individual packages on npm.

[reinhardt]

Thanks for the suggestions!

But in any case it would be good when patterns are separated, so that they can be easiely published as individual packages on npm.

Wouldn't this mean we need separate bundles for each pattern as well?

[reinhardt]

Also, a separate package.json for every pattern implies separate bundles as well, right? Or do you mean we should also add another package.json in the root, so that you can build both a combined bundle and separate bundles per pattern?

[MrTango]

So far i didn't merge js components, so they where completely separate. But the more i think about it the more i like the idea of merging them into one bundle like you do. With that in mind we would still need the patterns folder as top level for the bundle, but we could get rid of the resources folder, as in this case we would not move the other js apps in here. All files should stay inside the patterns folder, as we have other things people can create, so it would be good to keep the webpack stuff also inside patterns folder. But i wouldn't spread the js and css like it is now. One sub folder for each pattern.

To to sum it up:

• webpack config, package.json.bob, babel aso all one level down into /patterns
• below one folder for each pattern: pat-example1, pat-example2
• but keep it together in one bundle when building it

i hope i was not to confusing, it's getting late ;)

[reinhardt]

I've done some tweaks to the directory structure, but I didn't manage to put package.json, webpack.config.js etc. into the patterns directory. When doing this the node_modules directory gets created inside patterns/, and that leads to complications when calling sass. AFAIK it's also a convention to have the package.json in the root directory.

Do you think we can leave it like this?

NB I also added small fixes to the patternslib config call.

[thet]

I have reworked this template and branched off a version in mockup_pattern-2 and opened a new PR‌ here: https://github.com/plone/bobtemplates.plone/pull/516

I'm closing this now. We can always reopen this if my changes are troublesome.