Plugin config spread and multiple config states

[cbratschi]

Payload's plugin architecture has a design flaw. As outlined by the official specs, spread operators shall be used to modify the config in a plugin:

https://payloadcms.com/docs/plugins/build-your-own#spread-syntax

This leads to immutable config versions which are passed from plugin to plugin to create another one. Plugins often use closures and store a certain version known at the runtime of the plugin but this version differs from the final config after all plugins got executed.

For instance I had the issue today that the nested-docs plugin failed detecting drafts here in a collection hook:

https://github.com/payloadcms/payload/blob/main/packages/plugin-nested-docs/src/hooks/resaveSelfAfterCreate.ts#L23

const updateAsDraft =
        typeof collection.versions === 'object' &&
        collection.versions.drafts &&
        doc._status !== 'published'

In my case I moved adding collection.versions.drafts to a new plugin which was executed after the nested-docs plugin and nested-docs used an older config version here:

https://github.com/payloadcms/payload/blob/main/packages/plugin-nested-docs/src/index.ts#L57

It's difficult to difficult to fix this issue without changing the architecture from ground up. At least this issue should be part of the specification and plugins should avoid passing older configs to their hooks. These cases are very difficult to debug, it just fails. Re-ordering plugins might help but first the root cause has to be known.

I created this discussion to find a solution for upcoming Payload versions.

[AlessioGr]

You're 100% right here. We'll go ahead and fix the usage of config data in the nested docs plugin hooks.

I don't think there is a way to guarantee that this does not happen anymore and it's up to the plugin to do it right. To address this, we'll implement the following changes in our documentation

• Discourage unnecessary use of spread operators: For performance reasons and to prevent creating multiple copies of the config
• Caution against passing config data from the plugin in closures: Instead, it should be accessed through req.payload.config