The refactor within this is looking super clean, nice carving!

how do we determine what transformer to use on a mutate query?

Could we stamp each collection or node with metadata which references the transformer used? That would limit you to one transformer per collection in terms of CREATE operations. UPDATES could get the transformer used per-node in the mutation query resolver

I suppose we could also allow mutations to pass config args specifying which transformer to use for CREATE operations if they have multiple transformers for a single collection, or that might be better specified in the Flatbread config on a per-collection basis

how do we know where to save the file if the content type has wildcards in the path?

I think the default would be to place it at the root-most common path which matches the wildcard. If the user wants their content to go to a specific path, then I agree they'd be required to use the named wildcard fields in their query.

Ex. the user must specify the category and slug fields in their mutation, matching what they declared in their collection config:

path: 'content/markdown/posts/[category]/[slug].md',

based on your ideas I started moving metadata into _flatbread on collections.

"_flatbread": {
  "reference": "ab2c",
  "referenceField": "id",
  "collection": "Author",
  "filename": "daes.md",
  "path": "content/markdown/authors/daes.md",
  "slug": "daes",
  "sourcedBy": "@flatbread/source-filesystem",
  "transformedBy": "@flatbread/transformer-markdown"
}

Ex. the user must specify the category and slug fields in their mutation, matching what they declared in their collection config:
path: 'content/markdown/posts/[category]/[slug].md',

This is kind of what I was thinking too

I think the default would be to place it at the root-most common path which matches the wildcard.

Can you elaborate on this? not sure I understand

Could we stamp each collection or node with metadata which references the transformer used? That would limit you to one transformer per collection in terms of CREATE operations. UPDATES could get the transformer used per-node in the mutation query resolver

for create what if we default to the first transformer provided and allow it to be overridden by a field on the content entry? and for updates use the same transformer that was used to read it?

Could we stamp each collection or node with metadata which references the transformer used? That would limit you to one transformer per collection in terms of CREATE operations. UPDATES could get the transformer used per-node in the mutation query resolver

for create what if we default to the first transformer provided and allow it to be overridden by a field on the content entry? and for updates use the same transformer that was used to read it?

This sounds good to me

I think the default would be to place it at the root-most common path which matches the wildcard.

Can you elaborate on this? not sure I understand

If someone has: path: 'content/markdown/posts/**/**.md'

The default would be to add the new file to path: 'content/markdown/posts/<example-slug>.md'

If we allow a outputFallbackPath that could allow folks to specify a fallback place to put CREATEs in that collection if:

• they use the glob matching format for their content path like above /**/*.md
• they use named wildcards but did not provide the fields on where to place the content
  • path: 'content/markdown/posts/[category]/[slug].md'
  • The mutation query supplies null for the category field.
  • Then we use the outputFallbackPath

How do we create the slug? Does a slug make sense if it's not post / article data?

I'm almost tempted to say we should remove the * functionality and require named variable paths for everything

I'm almost tempted to say we should remove the * functionality and require named variable paths for everything

Yeah I was thinking about if we should remove the glob functionality as well. That would definitely simplify the moving pieces and force more organization.

How do we create the slug? Does a slug make sense if it's not post / article data?

Maybe this should be part of the config, an optional slugField option that accepts a field name to sluggify.
If there isn't a field that can be slugged, we could fallback to a known flatbread internal field.

But this will confuse people into thinking that the slugField option is also what generates the slug field for existing data, like stuff from NetlifyCMS

maybe we could add a config option to encapsulate CREATE mutations?

content: [
  {
    path: '../../packages/flatbread/content/posts',
    collection: 'Post',
    refs: {
      authors: 'Author',
    },
    onCreate: {
      slugField: 'title',
    },
  },
],

Yeah I was thinking about if we should remove the glob functionality as well. That would definitely simplify the moving pieces and force more organization.

I'd like to keep the glob functionality, just not the wildcard matching. I was thinking if we only allowed paths like content/[category]/[slug].md then we would be able to require those args for create and we wouldn't need to worry about slug or slug field because the required args would be specified in the path

also, I've been adding code to make it easier to support using custom fields for Ids in the future, by using

// a lodash path
_metadata.referenceField
// a copy of the id fetched from the data with referenceField
_metadata.reference