Problem

  • Frontend libraries are buried nilly-willy into System module.
  • Actual usage and "popularity" of frontend libraries cannot be measured.

Goal

  • Ensure long-term insight into usage of major frontend libraries.

Proposed solution

  1. Introduce the following modules:

    • jquery.module
    • jquery_ui.module

    (And potentially later: underscore.module, backbone.module; see #1149866: Add Backbone.js and Underscore.js to core)

  2. Add appropriate dependencies to core modules.

Related issues/projects

Comments

sun’s picture

Issue summary: View changes

Updated issue summary.

sun’s picture

Issue summary: View changes

Updated issue summary.

cweagans’s picture

-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.

mikey_p’s picture

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.

cweagans’s picture

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*.

mikey_p’s picture

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.

DamienMcKenna’s picture

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?

RobLoach’s picture

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.

DamienMcKenna’s picture

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

quicksketch’s picture

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.

sun’s picture

@quicksketch: Core sends usage data for individual core modules already due to #1036780: Drupal.org should collect stats on enabled sub-modules and core modules - AFAIK, the data is merely not stored/parsed/exposed on d.o yet.

nod_’s picture

I like the idea.

Crell’s picture

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.

webchick’s picture

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.

cosmicdreams’s picture

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

effulgentsia’s picture

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.

sun’s picture

I'm actually no longer sure about this proposal.

I think I created this issue since #1787222: [meta] Strategy for updating vendor JS libraries within a major stable version started to temporarily move into a different direction (but came back to a sane one in the meantime).

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.

RobLoach’s picture

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

sun’s picture

That's misleading. The links you pasted are pointing to standalone contrib projects.

Given the direction of #1787222, we'll have a much higher interest in the version of a specific library, instead of just the library itself.

In essence, in 2016, we want to figure out this:

Project/module/theme/component jQuery 1.8.2 jQuery 1.9.1 jQuery 2.0.1 jQuery 2.2.1 jQuery UI 1.9.12 jQuery UI 2.1.5 Backbone 0.9.8 Backbone 1.0.1 Backbone 1.6.4
Drupal\edit x x x x x x x x x
Drupal\node x x x x n/a n/a n/a n/a n/a
admin_menu\admin_menu x x x n/a n/a x x

Where those libraries are coming from does not matter in any way.

In fact, the info would ideally be parsed out of the hook_library_info() [or equivalent] code in all d.o projects, removing the dependency on update module usage statistics.

Essentially, if we want to do this change, then it would only be for moving the hook_library_info() declarations out of System module — but certainly not all, so the impact would be negligible, since system_library_info() would still exist.

nod_’s picture

Status: Active » Closed (works as designed)

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.

nod_’s picture

Issue summary: View changes

Updated issue summary.

sun’s picture

Issue summary: View changes
Status: Closed (works as designed) » Active

#1996238: Replace hook_library_info() by *.libraries.yml file is about the declaration/registration of libraries that a module may provide or ship with.

This issue here is about the opposite: Usage.

Version: 8.0.x-dev » 8.1.x-dev

Drupal 8.0.6 was released on April 6 and is the final bugfix release for the Drupal 8.0.x series. Drupal 8.0.x will not receive any further development aside from security fixes. Drupal 8.1.0-rc1 is now available and sites should prepare to update to 8.1.0.

Bug reports should be targeted against the 8.1.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.9 was released on September 7 and is the final bugfix release for the Drupal 8.1.x series. Drupal 8.1.x will not receive any further development aside from security fixes. Drupal 8.2.0-rc1 is now available and sites should prepare to upgrade to 8.2.0.

Bug reports should be targeted against the 8.2.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.6 was released on February 1, 2017 and is the final full bugfix release for the Drupal 8.2.x series. Drupal 8.2.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.3.0 on April 5, 2017. (Drupal 8.3.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.3.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.