[RFC] Show provided widgets

[PhillippOhlandt]

Hey,

now where we can include widget locations in themes, I would find it very useful when the extension store could list them.

My idea is to add that to the extra section in the composer.json. Something like

"extra": {
        "bolt-widgets": [
            "aside_top",
            "aside_bottom",
            "footer"
        ]
    }

or with a description

"extra": {
        "bolt-widgets": [
            {
                "name": "aside_top",
                "description": "Right before the latest entry list"
            },
            {
                "name": "aside_bottom",
                "description": "Right after the subscription form"
            },
            {
                "name": "footer",
                "description": "At the top of the footer"
            },
        ]
    }

Personally, I prefer the one with the description, because then it's easier for the user and can act like a little documentation. Also, more metadata is always better :)

I would take care of the implementation in the extension store then.

[GwendolenLynch]

Concept: ✔️
Using composer.json: ➖ (though I sort of lean toward ✔️)

Interested to see what others think though.

[ToBe998]

The second syntax would offer potential for future additions without breaking existing code. I'd go with that one.

[PhillippOhlandt]

Ok, because some people are against the idea. Let's just make a little poll.
👍 for the implementation in the extension store
👎 for no implementation in the extension store. But it will land on boltthem.es some day then.

Just add the 👍 or 👎 as reaction to this answer.

[jadwigo]

is it possible to read it from theme.yml? that might also be a place to look for it

bolt-widgets:
  aside_top:
    label: "Top widgets"
    description: "Right before the latest entry list"
  aside_bottom:
    label: "Sidebar widgets"
    description: "Right after the subscription form"
  footer:
    description: "At the top of the footer"

[PhillippOhlandt]

@jadwigo possible and would make @SahAssar and @GawainLynch a bit happier. But that would mean much more work for the implementation. It's easy to get values from the composer.json but when we want to parse the theme.yml we have to deal with different APIs for github, bitbucket, gitlab, etc.

[WedgeSama]

I agree with @jadwigo. The main goal of composer is to manage dependencies and not to provide information about theming.

In the case you have many widgets, the composer.json can become a bit heavy. I think put that stuff in another file can be more useful.

I will not necessarely agree for theme.yml, because it limit possibilities for next features. Something like provide.yml make more sense to me.

However, like @PhillippOhlandt said, this solution involve much work.

[PhillippOhlandt]

If we decide to use another file. All other things like icon and screenshots should be moved too. Otherwise its not very consistent. But that would be a big break. Maybe we keep everything in composer.json for now and move to another file with Bolt 4?

[GwendolenLynch]

Something like provide.yml make more sense to me.

Actually… TBH… I think I like the idea. Maybe going with .metadata.json or something else dotty/hidden

Maybe we keep everything in composer.json for now and move to another file with Bolt 4?

Nah, we just deprecate the old behaviour and read from both sources.

[PhillippOhlandt]

I like the idea of .metadata.json. Let's discuss that in slack#development, yo?

[PhillippOhlandt]

Ok, after a small talk with @GawainLynch we think it's a good idea to have a .metadata.yml file that looks like

icon: icon.png
screenshots:
    - screenshot1.png
    - screenshot2.png
widgets:
    - name: footer
      description: wololo

It will be the new place for the icon, the screenshots and of course, our widgets.

I will implement it in a way that the values inside the .metadata.yml override the values in composer.json.

That way we still support the definition in the composer.json but the .metadata.yml, if it exists, has a higher priority.

[WedgeSama]

I think it is not relevent to hide the file (the dot). Hidding file/dir like that is more for autogenerated stuff, ignoring mechanisms (.gitignore, .npmignore) or IDE specific files.

I think it will be better without the dot.

[PhillippOhlandt]

@WedgeSama: But @GawainLynch likes dot files :)

[GwendolenLynch]

Yeah, I totally disagree… there are dots on the box, damn it 😜

[PhillippOhlandt]

And we now have the .bolt.yml on Bolt 3. So keep it consistent :)

[rossriley]

I'm personally in favour of leaving the essentials as they are now in composer.json but since templates are already defined in theme.yml then it makes sense to me to define widgets in the same place too, I don't see any value in adding yet another metadata file since that is what theme.yml already does.

The reason icon and screenshots are in composer.json are because they are needed for the extensions store, although in principle we could just have them configured as fields on the submit form rather than needing to be in the composer.json, at the time it seemed like it may be useful as we may want to show screenshots on the /bolt/extend screen on the backend as well as in the store, but as yet this isn't the case.

[PhillippOhlandt]

@rossriley: If we move it outside of composer.json, I would do it for themes and extensions. Not in theme.yml for themes and something different for extensions.

Thing is, we don't know what stuff will follow in the future. And people convinced me that defining everything in composer.json would bloat the file. Having an extra file makes sense then.

[PhillippOhlandt]

And for the extra fields on the submit form: That's a bad idea. When people move files around or delete them in the repo and forget to update the store entry, the package detail page would be broken, etc.
And that will happen, because humans.

[SvanteRichter]

Well, variables in theme.yml are usually used in the template or by bolt, which isn't really metadata, right? It's actual data, since it's used by the system (like the templatefields definitions for example).

This would just be for extensions.bolt.cm and similar systems to read, not for actual use by the theme or bolt once it's installed (unless I've misunderstood something).