gatsby-plugin-manifest: Get icon/favicon from CMS

[ojohnny]

I have recently encountered projects where it would make most sense to reuse the same Gatsby repository for multiple sites (under the same parent company, which is reason enough to keep structure/layout as similar as possible). The sites do have different logos etc, which for the most part is easy to implement as we can get that info via GraphQL from the CMS (in my case WordPress).

However, the icon/favicon for a Gatsby project is now specified via gatsby-plugin-manifest, which seems to take a path to a file inside the repository. It would be nice to be able to source this from the CMS. At least WordPress have a setting for this under Appearance → Customize → Site Identity → Site Icon.

The only idea for a workaround I have in the meantime is to store all possible icons inside the repository and use an environment variable to select the one to use, but I think it would be good if a more flexible solution existed.

Ideas on how to solve this or other workarounds are welcome.

[moonmeister]

It's fairly straight forward to implement the ability at the plugin level. It's done in other plugins such as gatsby-plugin-sitemap. That said I think it'd be interesting if we abstracted this into the Gatsby level. It'd mean this functionality would be available to all plugins more easily and users can do as thy need with a consistent api.

I could see implementing this in 1 of 2 ways. first, allow options to be a function.

{
  resolve: `gatsby-plugin-manifest`,
  options: async ({ graphql }) => {
    const results = await graphql(`
      query {
        ...
      }
    `)
    
     return {
       icon: results.icon.path,
       ...
     }
  }
}

alternatively:

// gatsby-config.js
{
  resolve: `gatsby-plugin-manifest`,
  options: {
    name: 'My App'
    ...
  },
  query: async ({ graphql }){`
    const result = await graphql(`
      query {
        ...
      }`)
      
      return {
       icon: results.icon.path,
       ...
     }
  }
}


// elsewhere in Gatsby

const results = await query({ graphql })

const pluignOptions = deepMerge(options, results)

Potential downsides

1. I believe if you had a data source plugin listed in your config after a plugin making a query you'd wouldn't be able to access that data. This issue exists currently so it's not a huge problem but this might shine some light on it.
2. Plugin typings in editor might be much more helpful here. for example, the Icon config in the manifest plugin expects a path currently. That can still be passed but it might be tempting to pass a url or some other data type to the plugin expecting it to work. Some helper functions could be provided for special types like image inputs to help solve this issue and not make plugins resolve the same problem.
3. You could get an issue where 2 plugins are circularly dependent on each others data.

potential unintended features

1. A plugin like gatsby-plugin-sitemap could write data into the data layer such as the path where the sitemap is. then another plugin such as gatsby-plugin-robbotstxt could come, fetch that data for adding the sitemap to your robots.txt. This isn't necessarily a good or bad thing, just something to be aware of. This as a feature has crossed my mind before, but it maybe be nice if there was more structure around cross plugin state.