Move each major atomic frontend library into an own module

-1

jQuery is a very nice client-side base to build stuff on. If you don't want jQuery, alter it away and say goodbye to most contrib frontend functionality.

Why not? Isn't the point of Drupal that it's modular? Why shouldn't core be modular?

I think this could potentially make overriding these versions in contrib updates much easier as well. Just ship the identically named module as core has and it'll be overridden automatically.

Okay, so we provide jquery.module in core and we rely on that for core javascript. Cool. Now we're loading jQuery on every page like we already do.

Then, some contrib author comes in and decides that he likes mootools. Now those sites are loading both mootools and jQuery. That quickly turns into a gigantic CF.

I'm a firm believer in convention over configuration where it makes sense, and I think this is a place where it makes sense. If we don't want to use jQuery, that's fine, but if that's the case, then I think we should standardize on another library. Loading two gigantic libraries like that is *so bad*.

I don't think this issue has anything to do with loading multiple frameworks, as always that's possible now, and nothing in this issue would make that any easier or harder. If anything it'd be easier as you could conceivably disable all the modules that depend on a given library and then disable it.

What this issue is about (since I also brought this up over on the backbone issue) is that system module shouldn't give a shit what Javascript libraries your site uses.

Wouldn't #1542344: Use AMD for JS architecture resolve the need to physically separate the JS libraries out like this? I mean, what's more DX friendly than having the JS libraries load on-demand?

This doesn't just help decouple our core/misc directory, but also allows us to get a better grasp on where our module dependencies lie. Whether it's jQuery, Underscore, or something else entirely doesn't matter. What matters is knowing when and where those libraries are used is what's important. Decoupling them from System module will help that.

So how about just decoupling the JS from system.module rather than adding another layer of complexity?

Actual usage and "popularity" of frontend libraries cannot be measured.

If these were separated into separate modules, how would we measure popularity then? We don't report *enabled* modules in update.module to drupal.org, so would we calculate popularity based on dependencies? But if the top 3 contrib modules all depend on jquery.module, what have we gained?

I personally prefer the "always available" convenience of the libraries being in system.module. If you want the library, declare the dependency in hook_library() and then it's there for you. From a contrib DX perspective I think the current situation is great.

From an organizational perspective, I'd just like to see all the core libraries be moved into /core/libraries so they mirror the /sites/all/libraries situation.Then at least our directory structure would make sense. The contents of /core/misc is the biggest drupalwtf we have going on right now with libraries.

I like the idea.

I'm luke-warm in favor of this, on the grounds that anything that makes system.module do less is probably a good idea. We should be trying to eliminate system.module and the /misc directory entirely.

This would have no impact on which pages actually load jquery.js, or on how bad an idea it is to drop prototype or mootools in next to jquery. It's just a "where do we put files on disk" question, really. If we make jquery.module a requirement of standard.profile, most users won't even notice the difference.

Two questions:

1) How do we handle namespace collision between a JS library and a Drupal module/theme (or PHP library the Drupal module is wrapping around)? There are a lot of these frameworks that use fairly common names (e.g. ember.js and ember theme).

2) How does this work for modules trying to require a specific version of a given library? We can't really peg module version numbers to jQuery (for example) version numbers; this makes the dependencies harder to track.

1) is just a naming issue. Namespace the modules with "core_". Done (Ex: core_jquery.module, core_ember.module, etc.)

From an organizational perspective, I'd just like to see all the core libraries be moved into /core/libraries

Personally, I don't see a huge organizational difference between core/libraries/jquery/jquery.js and core/modules/jquery/jquery.js. The former is perhaps a bit cleaner in that there will be fewer directories in core/libraries than in core/modules. In any case, I think even if we have a core/modules/jquery/jquery.module, if we want to put the js file into core/libraries, we still can.

The main thing in this issue seems to be about moving entries from system_library_info() to FOO_library_info() and therefore requiring consuming modules (e.g., Views) that depend on a particular library to also add that as a module dependency in the module .info file. (e.g., views_ui.info would need dependencies[] = jquery_ui) or whatever. Personally, I see this as 6 of one, half dozen of another: not a big problem or benefit in and of itself.

However, if this lets people easily see usage statistics on the libraries shipped with core, for me, that tips the scale in favor of this. But for that, we need to get #1627676: Display stats on enabled components (e.g. modules included in a project) done.

As already mentioned over there, I think what we actually need are drupal.org usage statistics for hook_library_info(), or rather, declared dependencies within there.

If the library definitions were decoupled from System module, then we'd understand what modules use jQuery vs jQuery UI vs Underscore, etc...
http://drupal.org/project/usage/underscore
http://drupal.org/project/usage/backbone
http://drupal.org/project/usage/jquery_ui

Now we explicitly declare all dependencies so getting the info from library_info is accurate. With #1996238: Replace hook_library_info() by *.libraries.yml file it might make it even simpler for d.o to get the deps.

Updated issue summary.

I think the plan these days is to make core use as little js as possible and rely on single-purpose libraries that don't have large dependency trees. jquery ui is out the door, so is jquery, and I don't think many people use backbone/underscore in their D9 projects.

It'd be nice to have a sense of what is used/loaded on the different websites but I don't think we need it to move forward (or at least the intention of the issue and the technical solution are not aligned anymore).

This seems to be what's being accomplished in https://www.drupal.org/project/drupal/issues/3364673