As a beginning...
We have growing up community and crowd of extension developers.
Now we had many extensions, modules, themes that uses common (popular) JS and CSS libs, such as: bootstrap, jquery UI and so on.
Nowdays practice that kind of code are included in extension subfolder like: plugin/css and plugin/js.
As number of extensions are grows, I sometimes get an collision that happend when several extension tries to load same JS lib each of its own
). Same with common CSS.
Of course, If we have an CKEditor that uses CKeditor files in own folder and loads it only on edit pages - there are no problems. The collision with other plug using other CKEditor insignificant.
But, as example «elrte» editor uses own jQueryUI files, and if we need to use any jQeuryUI plug in edit pages we had two solutions:
Make some rules and recomendations for extension/theme developers about using common libs and files.
As I understand, JS and CSS subfolders in extension dir are made only for plugin related code and styles. And If we use common (or standard library as jquery_ui) or third party libs without any (plugin related) modifications we must place these files in root/js folder.
As a minimum in that case when these files are loaded on «always» basis. (If extension loads up some JS only on own «standalone» pages it's not so inportant).
I want to see you mentions about this.
And we need take it into account for «Centralized extension repository» that planned for Cotonti 1.0.
This has been annoying me recently, but I haven't got a perfect solution for this. Should we put them in separate "vendor" packages (like ones with package.json file)? Or should we teach our cot_rc_* functions some intelligence to determine same libraries and prefer newer versions if several versions of the same file are requested?
If compare this two suggestions: I suppose extending cot_rc_* is wrong way. It would require heavy logic, takes much execution time and still be very «breakable».
Somekind of packages sounds more attractive.
The main problem of this issue (resource duplicate loading) is solved with #1381 and based on using «aliases» for common resources.