Rather than modifying fields on an existing content type, is it a better idea to simply override the entire module that provides the content type?

[dearmond]

Rather than modifying fields on an existing content type, is it a better idea to simply override the entire module that provides the content type?

[mrkmiller]

I feel like this one is really a judgement call of the subprofile. If I was only adding a field or 2 then I would just override the bits that need changing. This way I would still get all the config for things like path alias, sitemap settings, and upgrades. Also if the base module provides hooks or classes that are being used then these would not want to be duplicated.

However, if it turns into an issue where more fields are custom than original, or if current fields need to work differently like allowing unlimited entries instead of a single one, then it seems like a complete module override would be better.

In general, I would say NO, don't completely override a module.

[dearmond]

Agreed.

I think this question is a spin-off of several of the others. To word it another way: are config overrides in subprofiles so inflexible that subprofiles have to replace the entire module every time?

The answer appears to be "NO". Config overrides in subprofiles seems to be pretty flexible, so it's a judgement call of the subprofile.