unfortunately, decoupling means abandonware look at com_weblinks for reference

If Joomla wolud do this for all components i.e. banners, contact, newsfeeds .. the system could be more modular and a slimmer. It could be a strategy, and a good one. With weblinks we have a good example how decoupling was made wrong.
In future versions .. who knows?

Been there, done that, failed. move on

The advantage of not decoupling code is that more people feel responsible for the code. Inclusive security issues.

It could be a strategy, and a good one.

Agree, but ... [go to the beginning of the post] ...

The advantage of not decoupling code is that more people feel responsible for the code. Inclusive security issues.

It could be a strategy, and a good one.

Agree, but ... [go to the beginning of the post] ...

Just to make it clear it is not about the Security stuff. The JSST is doing the same work for weblinks and any other official decoupled extension.

It is more about that noone wants to do the maintanince work of an decoupled extension. And as brian said been there done that failed. When we have a good plan and people who want to maintain that code for the longterm I'm sure Production will listen and this could be discussed but for now I'm not sure whether splitting more does help the few people to maintain it.

unfortunately, decoupling means abandonware look at com_weblinks for reference

Sorry but this is utterly wrong. All the project needs is to move the repo to Monorepo (eg one repo with all the packages, pkg_wrapper: the com_wrapper and the mod_wrapper). What was tried before was the totally opposite: multiple repos (each repo one package) and of course that will eventually lead to abandonware...

If there's a will there's a way...

It is more about that noone wants to do the maintanince work of an decoupled extension.

At the moment, this seems true. But I agree with @dgrammatiko - if decouplieng means "smaller packes and and features on demand" there would be as many attention on them. I miss weblinks - it is a useful component and can be used in different ways.

Just another point, just by the way: If you decouple you need not only volunteers for maintenance. You need also willing experts for this and that in any project. E.g. for es6.js . You can't rely on helping hands if decoupled and experts here are not interested anyhow in one of these projects or simply don't have the time.

You can't rely on helping hands if decoupled and experts here are not interested anyhow in one of these projects

Did you understood what I wrote? The repo is just gonna be reorganised. There's no difference with the existing repo part that you need one more command before start developing. The code base will be the same. The advantages are:

• Different release cycles
• optimal resources per project ( I don't use wrapper/banners/contacts/weblinks, etc why should I expand the attack surface with useless code?)
• Tooling is all it takes...
• Possibilities for devs to roll their own packages with complete solutions (eg an e-commerce by x company with the addition of some popular extensions by other devs)
• Modular is always better

And decoupling means also, that I can decide as Admin at any time (joomla Install/ Joomla Upgrade/ Running Joomla) to deinstall or reinstall components or plugins which I don't need and, as dgrammatiko stated reducing a possible attack surface by not having code laying around.
The abillity to extend the system at any time by trusted Joomla Dev components rather than possible shady ones would be another benefit.

And with decoupling, the Installer and Upgrade-Component could be extended with a more detailed Process, which may lead to less install time and/or less issues of any sort..

About specific components, in around 400 joomla websites developed in 15 years for Companies, Businesses, etc, that wants to have some revenue from digital marketing (so... not hobby websites), i have never used:

• com_banner
• com_contact
• com_newsfeed
• com_weblink

Decoupling is always good for security and maintenance.

The advantage of not decoupling code is that more people feel responsible for the code. Inclusive security issues.

I don't understand: a project has to be done for the convenience of "core" developers, leaving behind what is needed for end users?

round and round in circles we go.

Those who cannot learn from history are doomed to repeat it. Those who do not remember their past are condemned to repeat their mistakes. Those who do not read history are doomed to repeat it.

Slim core is our plan for years but we don't have the resources to maintain all the components

round and round in circles we go.

@brianteeman Nobody said here to follow the failed strategy (each extension on its own repo) so your comment is out of context. Monorepo is what everybody is doing these days because the failed approach of multiple repos wasn't a failure only for Joomla... Take a look on the symphony repo...

you cannot compare a development framework and a cms

you cannot compare a development framework and a cms

From a dev point of view they obey the same rules. It's just a bunch of files, how you arrange the files (packages or a copy of the deliverable) is all I'm talking about and essentially what monorepos are about