Returning a new config object from a plugin's configuration function breaks
Closed this issue · 0 comments
Describe the bug
In Discord we had the report that the following config in a plugin resulted in the defined custom fields not getting registered as expected and not showing up in the GraphQL API:
@VendurePlugin({
configuration: (config) => getCustomerConfig(config),
// ... rest omitted for brevity
})
export class DCustomerPlugin {}
export const getCustomerConfig = (config: RuntimeVendureConfig): RuntimeVendureConfig => ({
...config,
customFields: {
...config.customFields,
Customer: [...config.customFields.Customer, ...customerCustomFields],
User: [...config.customFields.User, ...userCustomFields],
},
})
Here we can see that the getCustomerConfig
is returning a new object instance, rather than mutating the config
object that was passed into the function.
To Reproduce
Here's a minimal reproduction:
@VendurePlugin({
configuration: config => {
return {
...config,
customFields: {
...config.customFields,
Customer: [
{
name: 'testField',
type: 'string',
},
],
},
};
},
})
class MyPlugin {}
It looks like the underlying reason for this is that internally, the ConfigService is calling the getConfig method in its constructor. This getConfig
method is using an internal shared config object named activeConfig
. Inside the core, it is expected that this object reference to activeConfig
is used throughout the app. However, returning a new object instance in the example above breaks this assumption.
The solution can be to take the result returned by the plugin configuration
function, and then merge it into the existing object reference.
Expected behavior
The above pattern should be supported, otherwise we are leaking out internal implementation details in a hard-to-understand-and-debug manner.
Environment (please complete the following information):
- @vendure/core version: 2.2.5
- Nodejs version: any
- Database (mysql/postgres etc): any