Bug Tracker

Opened 8 years ago

Closed 8 years ago

#13628 closed feature (wontfix)

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.

Change History (7)

comment:1 Changed 8 years ago by dmethvin

Owner: set to m_gol
Status: newpending

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.

comment:2 Changed 8 years ago by scottgonzalez

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.

comment:3 Changed 8 years ago by m_gol

Status: pendingnew

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

comment:4 Changed 8 years ago by scottgonzalez

Status: newpending

Why would you detect on selector-native?

Last edited 8 years ago by scottgonzalez (previous) (diff)

comment:5 Changed 8 years ago by m_gol

Status: pendingnew

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.

comment:6 Changed 8 years ago by scottgonzalez

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.

comment:7 Changed 8 years ago by Rick Waldron

Resolution: wontfix
Status: newclosed

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

Note: See TracTickets for help on using tickets.