I dont see anything wrong with this directory at all. It contains all 3rd party JS that we pull down via Grunt/Node.

All extension specific JS is still in the media root: https://github.com/joomla/joomla-cms/tree/4.0-dev/media

Updating these is easily done. You simply need to change the version number in here: https://github.com/joomla/joomla-cms/blob/4.0-dev/grunt_settings.yaml and run grunt

@mbabker @wilsonge some input here?

Sure, I understand that. My point is another one.
For example codemirror is specific to the codemirror editor and not meant to be used by 3rd parties. Because we may want to upgrade codemirror to v6 in future, but you would break each 3rd party extension that is using codemirror with that move. So you will have to stay on v5 for the life of J4.
Instead if you put extension specific media into their respective folders, you would be free to upgrade to the latest releases.

You will not be able to say it is fine (and actually should) to use jQuery by 3rd parties but not codemirror which lives in the same folder. That makes no sense.

So the main question here is imho if the libraries are meant to be used by 3rd parties.
If yes, put them into the vendor folder and keep B/C with it.
If no, put them into the extension folder (template, component, whatever).

@Bakual I understand what you are saying but

1. presumably we would only be upgrading a vendor file if it was b/c anyway - thats current practice
2. we want people to be using these instead of installing their own
3. if it is in the media folder then it can be overriden if required

Also looking through the list of files in the vendor folder I am not sure you can say they are extension specific which ones do you see that are extension specific

sorry I just saw that tinymce and codemirror are there - i missed those. I still dont see the upgrade issue

codemirror and tinymce I guess

what about cropperjs, dragula, minicolors, perfect-scrollbar tether and font-awesome? They all look very extension/use-case specific to me.

I understand the purpose of the media/vendor folder, but im not quite sure if it is a good idea to put all 3dp frontend libs in there.

If we expect 3dp to use those extension/use-case specific libs, thats not going to happen. They will continue using the new fancy stuff or the lib they found first at google. And even if they start using media/vendor libs, they will stop as soon as the first update breaks their code.

I dont see a real benefit in putting extension/use-case specifc libs in a common folder and suggest putting them back in the media/[extension] folder of the extension they belong to. I would only put general stuff like jq, b4 (and perhaps jqui) in such a folder.

If we put all stuff to media/vendor, we have to maintain extension/use-case related dependencies on a system-wide scope, which will lead to errors, B/C problems and testing complexity.

Yeah, lets just put them back in the original folders and let people core hack them again. +1

Sorry, i dont get your point here.
Why do you need a core hack, when we have our extension/use-case specific libs in media/[extension] instead of media/vendor?

Template devs can easily override them using media file overrides.
Component/Module/Plugin devs will use their own/different libs anyways for reasons i explained in my last comment.

Im not talking about general stuff like jq and bootstrap and im not suggesting that we should load libs directly from a com_xxx/assets extension folder.

I see more problems than benefits when we put extension/use-case specific libs in the /media/vendor folder.

2. we want people to be using these instead of installing their own
3. if it is in the media folder then it can be overriden if required

@brianteeman If we want people to be using these instead of their own, then it's fine to be in the vendor folder. Absolutely.
As for point 3, that was maybe me not clear enough. With extension specific folder I meant an extension specific folder within /media/. Eg /media/com_foo or /media/plg_content_bar. Like we do today to allow it being overriden.
Not in /components/com_foo or plugins/content/bar.

As for extension specific files, that's indeed mainly the codemirror and tinyMCE I saw.
There may be more but I don't know what they are.

• "minicolors" looks like specific to the color formfield (we need to keep B/C here anyway since it's a library field)

Others look template specific (eg "perfect-scrollbar"?).

@dgrammatiko @wilsonge can you guys make a decision please and then either close this or change the file locations

@wilsonge This is waiting on a decision by you for almost exactly one year - I assume it fell of your radar

As we are now in rc and code freeze I am assuming that this is not going to be addressed. And if it isnt addressed in 4.0 then it cant be until 5.0

Please either close this or mark it re-evaluate for 5

There is no point in keeping issues open if they are not accepted

My 2c here we shouldn't ship 3rd party js as standalone scripts. The way we should have treated those dependencies was showcased in #33773 That would have solved all the issues if applied to all the 3rd pt scripts ?‍♂️

Disagree for the same reasons that @Fedik stated in #33773

Disagree for the same reasons that @Fedik stated in #33773

@Fedik's comment is totally wrong:

Developers may want to use it somewhere in their extension.

Developers should do their scripts dependencies like import { whaterver } from 'npm_whatever_package. It's 2021, modules are a thing since 2018. This was the old way of doing javascript delivery...

This should be closed, J4 shipped with the vendor folder