Bug Tracker

#13628 closed feature (wontfix)

Opened March 19, 2013 08:12PM UTC

Closed March 19, 2013 08:52PM UTC

jQuery could expose which modules are included in current build

Reported by: m_gol Owned by: m_gol
Priority: undecided Milestone: None
Component: unfiled Version: 2.0b2
Keywords: Cc:
Blocked by: Blocking:
Description

Currently, there is no easy and safe way to detect which jQuery modules are built in if using a custom build. Some plugins might need to use that info. For example, if one excludes the effects module and plans to animate using CSS transitions, a plugin using animate will break. However, if the plugin could detect if the effects module is present, it might define an alternative code path which animates using CSS transitions.

Another issue is API consistency when using plugins. If one excludes event-alias, a plugin defining custom events might detect it and not define a helper jQuery.fn.eventname method.

I don't have any data related to how useful such an option would be, it was just sth that came to my mind and I thought it might be worth to share with devs and see what others think.

Attachments (0)
Change History (7)

Changed March 19, 2013 08:15PM UTC by dmethvin comment:1

owner: → m_gol
status: new → pending

Wouldn't we just advocate API detection for that? IOW if you know $.fn.animate() is needed then check that it is present. That's what the unit tests currently do.

Changed March 19, 2013 08:16PM UTC by scottgonzalez comment:2

Seems to me like this wouldn't be very useful. Feature detect on what you want to use. The event alias case seems pointless. The purpose of excluding event-alias is to save bytes. Writing more code to conditionally not create an event alias in a plugin would be counter-productive.

Changed March 19, 2013 08:20PM UTC by m_gol comment:3

status: pending → new

You might be right that a simple API detection will work in most cases.

I wonder about selector-sizzle and selector-native, though, could they be detected in a similar way? (of course, even if they can't it doesn't have to necessarily mean it's useful, after all).

OK, maybe it wasn't the greatest idea of all times. :)

Changed March 19, 2013 08:22PM UTC by scottgonzalez comment:4

_comment0: Why would you detect on `select-native`? → 1363724550465075
status: new → pending

Why would you detect on selector-native?

Changed March 19, 2013 08:25PM UTC by m_gol comment:5

status: pending → new

Someone might hit a bug in native querySelectorAll that Sizzle workarounds and which correctness is needed for the plugin and still not want to include the full Sizzle. But, of course, it might be that it's too much of an edge-case to be worthwhile to support such a use case. Your call.

Changed March 19, 2013 08:26PM UTC by scottgonzalez comment:6

Opting into selector-native means opting into tons of bugs. Plugins authors should not worry about this.

I'll leave this for Dave, but I would expect this to be closed wontfix.

Changed March 19, 2013 08:52PM UTC by rwaldron comment:7

resolution: → wontfix
status: new → closed

jQuery only supports the "one true build" which is the stable, fully built release