Exclude core-store.strapi_content_types_schema by default.

[Jen Tak]

The contents of the core-store.strapi_content_types_schema config are a mere mirror of the individual content types' schemas. In other words: this config cannot be independently edited, it is fully dependent on the schemas.

This causes several troubles:

1. It inflates the diff in commits. When I change the schema, I also have to remember to export and commit the config. The changes in both files are almost identical, needlessly inflating the diff and making code review harder.
2. When I forget to do so and the config files get misaligned with the schemas, Strapi aligns the config in DB with the schemas on every startup. This leads to confusing situations where config-sync diff reports non-empty diff even when run immediately after config-sync import.

I currently work around this be explicitly excluding this config from the sync with:

"config-sync": {
  config: {
    excludedConfig: [
      "core-store.strapi_content_types_schema",
    ]
  }
}

If I didn't miss anything, there is no point in syncing this particular config. It would be good to consider to exclude it by default or maybe point it out in the docs.

[Boaz Poolman]

Hi @goodhoko,

Thanks for reporting this issue. I definitely see why this config could be excluded by default. I wonder why this config exists at all?

Seeing as the config gets automatically updated based on the schema I think there is no reason why not to exclude it. The behavior will be the same and the config will be present on all envs regardless of it being excluded.

If you want you can put up the PR. Otherwise I’ll make the change myself.

[Jen Tak]

I wonder why this config exists at all?

I guess it's there for easier and faster access or maybe to have a side-storage when schemas are being updated with the content-type-builder. But it would be best to ask someone from the Strapi team. .)

I did a quick greping around Strapi's codebase and couldn't find any usages of this config. But that's wrong as there must be at least something that creates in the first place.

The behavior will be the same and the config will be present on all envs regardless of it being excluded.

Yeah, that's what I'm seeing at least in my app.

If you want you can put up the PR. Otherwise I’ll make the change myself.

I'm quite busy now and I'm honestly not sure where to implement this exception. So, if you could do it, that would be awesome! <3

[Boaz Poolman]

This was released with v1.1.2