Wrap inline JS in a self-executing closure

I agree.. this is a huge burden, specially when none of the jQuery plugins work out of the box.

Js handling needs to be rethinked, #1033392: Script loader support in core (LABjs etc.) and that would pretty much take care of your issue.

#1332752: Coding standards: add jQuery multiple version naming conventions

+100000000000000

Beautiful reasoning for this issue, I couldn't have said it better.

For further ammunition, the current convoluted convention also causes global variables and functions to break in unexpected ways that aren't documented with the change notice.

For example, you might think you could just wrap your js files that use jquery in (function ($) {//jquery code here}(jQuery)); but any global variables or functions within this function will not be accessible from other scripts or from code that runs outside this scope. This can introduce the need for major rewriting in a way that is far from sensible or intuitive.

The cure is so much worse than the poison, and as a developer, the introduction of this convention was one of the most frustrating changes in Drupal core that I have ever experienced. I can't even express politely how bad of a decision I think it was.

Is it possible to get this back in 7.x as well? I, and I'm sure many other developers, have piles of JS code that need to be rewritten in order to port to D7 and all for the sake of the use cases of .01% of the user base. It's just crazy when you really measure out how much time and energy a decision like this costs developers down the line.

No, this cannot be changed in D7 anymore. However, you can simply override misc/drupal.js in your theme and remove the offending jQuery.noConflict(); line - though you need to watch out for updates to that file afterwards. Alternatively, you can add a custom getjqueryback.js file that runs right after drupal.js and which only contains $ = jQuery; in the global scope. The latter option might be worth a contributed module even. Ping me in IRC if you want to do it cleanly.

So with sun's help, I've created a contributed module that allows you to use the $ for D7.

It can be found here:
http://drupal.org/project/jquery_dollar

@sun: Out of interest, why would it be considered an API change to remove the noConflict() configuration option? I don't believe it would stop existing code from working, and would make other code easier to work with.

First, releasing $ so it's not attached to jQuery isn't about making Drupal one size fits all. The Drupal internal JS is very much tied to jQuery and you can't just swap it out for another library sitting at the $ variable. APIs aren't compatible and JS will break. But, other libraries have been known to use $ just like jQuery does. By core running in noConflict mode we are able to integrate other JS libraries into Drupal without breaking JS.

If we remove noConflict mode we remove a feature some people asked for. I was part of a number of conversations where someone wanted to integrate another library for one reason or another. D7 is the first version that does this cleanly.

Second, I do understand some people would like to make $ = jQuery because they don't want to integrate other libraries. If someone does that and then uses $ in their own module it would make it incompatible for people who are using other libraries that use $.

Some notes....

• jQuery plugins should still work as long as they use the jQuery plugin pattern. If they go outside of that all bets are off. But, that would mean a plugin is going against the jQuery plugin pattern that's recommended and documented. If there's a bug tracker for a plugin that doesn't work I'd file a bug.
• If you use the module pattern, jQuery plugin pattern, or many of the other recommendations this isn't a problem.

Now, for the opinionated part....

I want to be careful to use JavaScript best practices. Just like PHP where you can write absolutely horrible PHP and have it work you can do the same with JavaScript. But, we have best practices, standards, etc. For JavaScript we need to follow some form of best practices (some of this needs to be worked out). I would start with a base test from JSHint (it's a little looser than JSLint and what jQuery itself uses).

I've written A LOT of JS against Drupal 7 and have had no problems at all.

One big thing we need to consider is the effect JS can have on other JS. So, module A inserts some JS in the page that unknowingly affects the JS module B inserts into the page. We need to help these two modules isolate their code from each other in such a way they don't mess each other up. And, there are best practices for this. A nice read is up at http://www.adequatelygood.com/2010/3/JavaScript-Module-Pattern-In-Depth.

The initial issue referred to mainstream jQuery that doesn't run or using a wrapper function. The wrapper functions are used as a pattern for a reason. When used poorly (like we do) or not at all JS can mess with other JS. To call out some of this I (and have some fun poking holes in our code) I wrote the a-hole module.

Just like there are a lot of bad PHP snippets on the Internet there are a lot of bad jQuery ones. I've heard a lot of complaints from JS people about them just like we so often have complained about bad PHP snippets. There are even good snippets from authors who write to people who know what their doing and assume you'll use this in a smart way in your own code. It's not as easy as blindly dropping JS into a file that you found on the internet. You need to understand a little of what's happening. You already have to do that with Drupal module code.

So, we can move towards better JS quality, JS that JS people like, JS that doesn't but heads with other JS in the page.... or we can regress. I'd like to see conversations like this be about helping us move in a better direction.

I have to agree with mfer here. Our mantra for our own code is "we don't babysit broken code". jQuery-using code that isn't protected against $ in jQuery-standard ways is broken. We should not babysit that.

We already do that for PHP code. Lots of older corporate libraries (like payment gateways especially) rely on a couple hard coded functions that print stuff themselves and use globals, on the assumption that you'll just paste make_form_elements_for_payment(); into your HTML file somewhere. That code is broken, it will not work with FAPI, and we don't support it. Period.

"Random JS snippets on the Interweb" should be treated the same way.

Yes, we can, and should, except a certain level of standard knowledge of how to do "correct" Javascript, as well as PHP. We're a big enough project that we can't not.

jQuery-using code that isn't protected against $ in jQuery-standard ways is broken. We should not babysit that.

Crell, I think you need to be a little more careful about your choice of words here. Saying code that utilizes the $ is broken is ridiculous. You might say that it's taking up a portion of the global namespace that other libraries could want, but the code is not broken - it works. In fact, that's how it was intended to be written. It might not be compatible with other code, but that's a long shot from being broken. Go have a look at all of the code displayed on jQuery.com - are you really saying that all of the code written on the website of the world's most popular javascript library is broken? Maybe you need to reexamine your definition of the word.

Global namespace is delicate and important, that's obvious, but it's also necessary. You could use your same logic to argue that the code in drupal.js that defines the global 'Drupal' variable is broken, and that would be just as ridiculous. What if another library wants to use the 'Drupal' var, are we going to say that core is broken and then go 'fix' it?

You can see that at some point, you just have to allow something into the global namespace, or you can't do ANYTHING.

Drupal depends on jQuery and has a long history of doing so. Using other libraries that make use of the $ is the exception not the rule. It seems to me that the small percentage of users that want to deviate from the norm should have a solution that deviates the norm. It just doesn't make sense to change the norm just for them.

I wrote a contrib module that let's jQuery operate normally by referencing the $. Why can't prototype users (or users of other libraries that want the $) do something similar?

I vote: won't fix/not a bug (not that my vote means much).

I honestly have no idea what this issue is about. I can use $ in my Drupal 7 js and have it mean jQuery. I can also use $ in Drupal 7 js to mean something entirely different.

@andremolnar:

The ability to use the $ symbol as a reference to jQuery by default was removed from Drupal 7. If you want some additional background on the issue, you can read: http://drupal.org/node/125030

Since, as you say, you have no idea what this issue is about, maybe refrain from voting on it :P

Please let me rephrase.
I have no idea why not having $ reference jQuery by default is a problem. In short, I am not convinced by the information presented in this topic that a) a problem exists and b) the proposed solution is a good idea.

To me it sounds like the primary problem that caused this issue is inline JS.

And indeed, it's a tad complicated to write the required, proper JS, including jQuery wrapper, in PHP.

(FWIW, I don't see any issue with plain JS in .js or .html or .tpl.php)

Thus, how about automatically adding the wrapper for inline JS to resolve this issue?

(ideally, using a separate attribute/property in the drupal_add_js() $options to be able to opt-out of the automation)

@sun: Personally, I think all of the reasoning cited in this issue applies just as much to inline js as any other type - it wouldn't feel like a resolution to me, and I think being expected to write closures in your js files but not in your inline js would cause even greater confusion.

You could use your same logic to argue that the code in drupal.js that defines the global 'Drupal' variable is broken, and that would be just as ridiculous

In actual fact, several other JavaScript libraries use the `$` variable for their own purposes (Prototype.js to name one). You could hardly claim that non-Drupal code would likely use `Drupal` as a global variable name?

are you really saying that all of the code written on the website of the world's most popular javascript library is broken?

Just the code that does not adhere to jQuery’s own coding standards. As defined in the plugin authoring guide, plugins are not supposed to use the `$` global variable: http://docs.jquery.com/Plugins/Authoring

@mikl

In actual fact, anyone could use the 'Drupal' var, just like anyone could use the '$'. You wouldn't want to, because that would break Drupal. By the same token, I think if you want to use other javascript libraries, you should configure them to use another namespace besides '$', because it's already taken by Drupal (or rather, one of its core components). Obviously, it is less likely that you will have collisions with 'Drupal', but if another javascript library were to use the name, you wouldn't abandon your own name in order to be compatible with it. I think the same logic can apply to the $, since it has been a part of Drupal core for so long.

As far as the documentation you are citing here: http://docs.jquery.com/Plugins/Authoring, it is very clear that this is the standard for writing plugins with jQuery, and not coding standards for writing all jQuery. Just look directly on jquery.com homepage, you can read: What does jQuery code look like? Here's the quick and dirty:$("p.neat").addClass("ohmy").show("slow");

The real question for me is, should Drupal core be jumping through hoops in order to support other javascript libraries out of the box, or should the extreme minority that are the users trying to use multiple libraries that conflict with each other by default be jumping through the hoops in order to use the Drupal.

To me it seems obvious that it's the latter. Let those users turn on jQuery.noConflict themselves, let Drupal developers get back to writing simple code.

@justindodge your premise that "jQuery is not supported out of the box in Drupal" is wrong. There is a very clear and well documented method of using jQuery within the Drupal ecosystem. Additionally, using 'Drupal' to represent something else in another library is just as likely as using 'jQuery'; your argument here is also invalid.

I am happy that you wrote a module that will allow users to get the '$' object as jQuery as default, this will allow the small subset of users who use jQuery plugins that are written incorrectly to work. Good job. I could also see a branch of major themes with the '$' represented as jQuery by default gaining popularity within the 'noobie' themer community.

@calvintennant : Saying that "jQuery is not supported out of the box in Drupal" is not even remotely my premise. It is not remotely the case. I can't fathom how you managed to interpret me that way.

What I said was, we shouldn't have to jump through hoops in order to use jQuery in Drupal. We shouldn't have to go through these hurdles just so jQuery is compatible with other libraries out of the box.

Let me stop and define 'jump through hoops' as:
1. Having to refactor all jQuery code written for Drupal 6.x and prior
2. Having to use special closures to access jQuery for any new jQuery code or any standard jQuery code that you might be using from other sources - NOT PLUGINS. "Standard" means code written the way you see it on jQuery.com
3. Using closures around jQuery code means that those segments of code can no longer declare in the global namespace - I've run into a lot of errors when using jQuery code from other sources (NOT PLUGINS) that is split into multiple files because they expect to be able to reference those global vars which are no longer global.

this will allow the small subset of users who use jQuery plugins that are written incorrectly to work

Who's talking about jQuery plugins? I've already mentioned very specifically that this issue should not pertain to jQuery plugins, and it's been mentioned previously that jQuery's own coding standards declare that they should use closures. Let's say it a third time: WE'RE NOT TALKING ABOUT PLUGINS

jQuery is part of Drupal core. I just don't get what is so insane about putting the burden of avoiding namespace conflicts with the $ on those libraries and/or contributed modules that want to use a javascript library that is non-core. I'm not suggesting that other libraries shouldn't be compatible with Drupal, I'm saying they should be responsible for it. It's not that hard and it saves most Drupal users a lot of effort, especially when we are talking about upgrades and migrations.

Good job.

...'noobie'

Now that we've established there is not one relevant statement to this issue in your comment, maybe you have something else to say. Hopefully your next comment will be devoid of the rudeness and snide attitude now that you've taken time to understand what I'm saying. I'm sure everyone will appreciate it if we can keep this to a strictly technical discussion.

@justindodge: If code written for jQuery is not following jQuery-specified (and well-established Javascript-wide) standards for how to write robust code that works around design failures of Javascript, then yes, it is broken and I will call a spade a spade. Just because it executes doesn't mean it isn't broken.

Similarly, PHP code that relies on global variables and assumption that you are printing random form elements to a mostly-HTML page is broken. It may run, but it's still fundamentally broken. (And yes, there is a fair bit of Drupal code that relies on globals. It is broken. Period.)

And I don't mean that you should never use $ to refer to jQuery. There's a very clear way to do so, with a self-executing Javascript function. It is well-understood by anyone who knows how to write Javascript these days that you have to do that to protect yourself against global leak. Examples on the jQuery front page aren't showing that, duh. That doesn't mean good jQuery code isn't doing so.

@crell: Your definition of broken is just plain not the same as many people's. For the sake of clear communication I can only suggest you be verbose when tossing that term around and expand on what you mean by it, because you are going to find a lot of disagreement about the semantics. To me it sounds like you are equating 'broken' with 'not according to best practices', and while it may not be a bad philosophy to try to live by, it's certainly not universally agreed upon.

This is the first time I have heard that the convention of self-executing javascript functions protect against some kind of memory leak. In fact I have seen other examples of how to get into leak troubles by making global property assignments from within that sort of closure.

I'd be happy if you could provide some resources or examples of that, I haven't been able to find anything after a cursory look up.

Not memory leak. Leak of variables into the global namespace, which causes collissions. The global namespace in Javascript is widely regarded as a design flaw that we have to hack around.

See the links in #9. Also try Javascript: The Good Parts by Doug Crockford, the original inventor of JSON.

What you're asking is to remove from Drupal a feature that was introduced in accordance with industry convention for safety to work around design flaws in the language so that "random script found on a blog somewhere" can work without modification. I do not believe that is a good policy, for our Javascript code or our PHP code. Drupal actively doesn't support dropping an HTML form into a node body or into a print statement, either, and that is a very good thing.

@crell: I understand the arguments around global namespacing, but calling jQuery.noConflict in core doesn't really do anything to address namespace collisions, it just changes one global for another. You can call $, or you can call jQuery, they are both global.

Suggesting that people write in closures is all well and good, and I encourage and consider all suggestions of best practices, but noConflicting jQuery does not force people to write code that doesn't rely on the global namespace, all it does is force users to change their conventions. At the end of the day, people can access jQuery in a global way all they want, they just can't use the $.

Why not continue to suggest the convention you feel is best without forcing a change in convention that doesn't necessarily do anything to encourage good practices? This is not just about supporting a "random script found on a blog somewhere", it's about all jQuery code written for Drupal 6.x and before.

Are you actually saying that a global generic variable name, that is known to be used by multiple projects for different things, is the same as an obviously namespaced variable that no other project is ever going to stumble on as a name by coincidence?

@crell : I'm not suggesting that in the slightest. I'm saying that the $ has been part of Drupal core for a long time, changing the convention is costly in effort, and that if other people want to introduce a javascript library into their Drupal site, the burden should be on them to avoid colliding with the very few core global variables that are namespaced by Drupal, namely 'Drupal', and '$'.

Well, "in the beginning"™before sexy JS libraries, $() was used as a shortcut to document.getElementById() because at the time, getElementById wasn't available everywhere and you had to use layers[], all[] and this kind of obsolete things. This is the reason why so many libraries used/are using $ as their main entry point.

Which mean by using $ you keep the burden it's associated with. I'm very happy Drupal choose not to do that and I really hope there is no going back. JS is very flexible, you can implement it in contrib without problem. That should never see the light of day in core, I don't want to go back to the good old times of the first browser war please.

#27:

changing the convention is costly in effort

So adding two lines of JavaScript to your code is a costly effort?

If you choose not to follow best practises when writing JavaScript code, that’s your choice, but there’s no reason for Drupal to support sloppy JavaScript code, if that support makes life harder for those that need to use other JavaScript libraries that use `$` – or potentially, just a different version of jQuery for some parts of the code.

Exposed $ to global, it's indirectly encourage drupal modules authors to write dummy code.

Changed title to reflect what this issue is actually about.

So adding two lines of JavaScript to your code is a costly effort?

It is wearying having to repeat myself. No, two lines of code is clearly not a costly effort and sounds very much like a typical straw man argument.

When you are migrating a whole site with perhaps dozens of js files, it starts to get costly, especially because those two lines you're talking about (assuming your are referring to the closure, i.e. self executing function) change the variable scope of all that code. That can mean pretty big potential rewrites for your function and variable access depending on how it was written.

Now multiply that site by dozens of sites, and those dozens of sites by many thousands of users, and you've got yourself a costly effort.

Exposed $ to global, it's indirectly encourage drupal modules authors to write dummy code

But exposing them to the jQuery global doesn't encourage it? It's 6 of one, half dozen of the other.

Look guys, I give up. I understand the reasoning by this change. I understand best practices. I get it all.

But here's what's frustrating - I'm down here on the front lines, writing websites with Drupal every day. Changes like this have a real impact on me and the companies I work for, and tons of other developers too. All of the engineers on this discussion are citing reasons of practice and so forth, but down here in the world of product development, 'best practices' means another thing, which is balancing the best way to engineer something, versus getting it done efficiently and within the budget, because if you can't do that, you just end up with nothing at all.

So here's my last point - Just try to even consider the idea that there is more to the equation then just what's best from an engineer's perspective. These things cost real time, money, and effort and everybody in this discussion is seeming to trivialize that.

Maybe this is what's best for Drupal in the end, maybe people will go on using the jQuery global, maybe they'll all download my contrib module. Who knows? You can't babysit coders and this convention doesn't change that.

All I'm asking is to give a little credence to the idea that saving the Drupal community some time and effort is valuable, even if its at the cost of, god forbid, the ability to use a convention that's not desirable in some opinions. Maybe it doesn't win out at the end of the day, but it has value. Give it some value.

justindodge: We get it. Really. But you're making the classic "Backward compatibility" argument, which has been around Drupal since there has been a Drupal. Drupal has always favored "improve the quality of the system" over backward compatibility. There's pros and cons both ways, but that is the approach Drupal has taken for a decade now. If we wanted to change that, we have to rethink the way we design, well, everything. And that means doing more, not less, of the sort of code segmentation you're talking about. See: http://www.garfieldtech.com/blog/backward-compatibility

Maedi: That sounds like a viable thing to do, however. Retitling.

crell: As a working Drupal developer, it can be quite a frustrating philosophy in some circumstances, but I suppose there is no arguing that it's the one you have in place. It can really make Drupal a tough sell in some commercial situations, but all one can really do is voice an opinion out here on the dusty trail of the issue queue every now and again. Like every healthy system in the world, I think Drupal core engineers need a healthy dose of contrasting opinion to stay in reality. If you get too carried away with "improving the quality of the system", you will alienate users, and I don't think that is the goal.
--
As far as the inline wrappers go, it could be a helpful time saver, and I definitely think that it should come with a variable to switch that wrapping on or off. I think it should be off by default, but in the following manner:

Rather than using the $options to flag the wrapping, what about making a new value available for $type. Maybe 'jquery', or 'inline-jquery', 'jquery-closure' etc.. since we are very specifically making a closure with the jQuery var available as $, this value for $type would be helpfully descriptive.

Let 'inline' remain as is - this might help ease backwards compatibility (ironic I know, given our conversation). The biggest reason I can see for this is that people may already have started wrapping their inline code in closures, so leaving the way this is output might save a little more confusion and rewriting.

Lastly, given that the root of this whole issue is compatibility with other libraries, inline JS should not be wrapped by default because of what http://docs.jquery.com/Using_jQuery_with_Other_Libraries has to say:

Use the following technique, which allows you to use $ inside of a block of code without permanently overwriting $:
(function($) { /* some code that uses $ */ })(jQuery)
Note: If you use this technique, you will not be able to use Prototype methods inside this capsuled function that expect $ to be Prototype's $, so you're making a choice to use only jQuery in that block.

This remark will not address the issue directly (sorry), but since everyone is already here...

The Drupal philosophy (improvement over backward compatibility): I mentioned once that this encourages laziness, and got jumped on by deeply offended core developers, but I had a special meaning for "laziness" in mind. As a programmer, I know that feeling free always to break past conventions can at times result in better, creative solutions, but it can also encourage us to not take the time and effort to look for solutions that do preserve existing work. Look at D7: a wonderful, almost mysteriously wonderful CMS; but the instant it was out the door, containing bugs so fatal that the site was totally crashed if one executed update.php, and D8 was already on the drawing board, with reliable D6 now in line for loss of support.

Look also at the long trail of lost modules - worked in D4.7, or 5, or 6, but the author lost the stamina at some point to keep on plodding on making endless API changes. Compare this with Linux - vastly more complex, but with a stable API. Yes, there are lost linux programs, that ceased working at some point when the c libraries evolved too far for them, but they are in a minority, and recompiling fixed most of them.

Here's what I think the core developers should do: put out a version (D7, say) then PLAN the next version to only contain compatible changes. See how much you can do within the limits of the API you delivered in D7. After coming up with a D7-compatible D8, then and only then free the API again for revamp in D9. I think the exercise would do wonders for widening the vision of the core programmers, whilst giving module developers some encouragement to keep on supporting their work.

I hope the relevance of this to the issue under discussion is clear. To make it explicit, look back at #15: sun found a way to do it with both forms of compatibility (support for old code and also other js modules). Seeing that possibility took vision of a kind that the core development philosophy ensures is very difficult.

rhouse: Please read the blog post linked in #35. It speaks directly to your point.

Thanks Crell, that discussion is really informative and makes a lot of things much clearer. If compatibility cannot be achieved, there may need to be thought of supporting more than one old version, even if only for security fixes.

@justindodge I'm in the front lines writing JS that runs in the scope of Drupal as well. It was a being thrown into these front lines that helped me into better JS patterns and practices.

In Drupal 7 you could use a snippet like this to wrap your inline code:

function jquery_inline_wrapper($snippet) {
  return "(function($) {\n" . $snippet . "\n})(jQuery)";
}

I'm going to be for good practices in our JS code and in helping others get there. If you didn't read the post at http://www.adequatelygood.com/2010/3/JavaScript-Module-Pattern-In-Depth it's a worthy and enlightening read.

Contrib, as jQuery plugins, should not rely on a $ being available.

if this is for your own scripts, please see #40 for a good solution.

@nod_ The issue is no longer about relying on the $, but about facilitating the implementation of closures when using drupal_add_js for inline javascript. It's not really helpful to restate your opinion on the $ and it no longer addresses the issue.
Unless we've reached a consensus that there is no merit to modifying drupal_add_js to include some assistance for inline closures, I don't think it's appropriate to mark the issue as closed.

As far as the inline wrappers go, it could be a helpful time saver

This is also your opinion and you're not giving a lot of hard facts to back it up. regardless of the possible switch mechanism.

Rather than using the $options to flag the wrapping, what about making a new value available for $type. Maybe 'jquery', or 'inline-jquery', 'jquery-closure' etc.. since we are very specifically making a closure with the jQuery var available as $, this value for $type would be helpfully descriptive.

This does not scale. What if i want to create my own 'type'? This will add a whole lot of PHP code to work around unproper javascript. It will also encourage people to come up with js types and not fix their javascript.

@nod_
Yes it is my opinion that closures for inline JS could be a helpful time saver. I don't have or need facts to back it up, it's just a simple opinion based on observation. If you or others share the opinion, we could call it a good idea. I'm not sure why the lack of facts was necessary to mention.

This does not scale.

Huh? It works exactly the same as the current implementation of adding inline javscript.

What if i want to create my own 'type'?

Maybe you are confused about what's being discussed. First, there is no creating your own 'type' - if we collectively agree that a new available value for the $type parameter of the drupal_add_js function is a good idea, then that is the end of the idea.

This will add a whole lot of PHP code to work around unproper javascript.

The amount of PHP code necessary to accommodate this is very, very small. See #40 for an example - that plus a couple other lines to check for $type is what we're talking about.

I'm not sure why you're calling anything "unproper" javascript, the point of adding a helper to wrap jQuery based javascript in closures is to make sure it conforms with everyone's idea of proper.

--
Just so we're especially clear, this is what it would look like:

//'inline-jquery' works exactly like 'inline' except it will be wrapped in a closure,
//so it's safe to use the '$'
drupal_add_js('$("body").append("Hello world");', 'inline-jquery');

//This is what actually gets added
//(function($) {$("body").append("Hello world");}(jQuery)

It is necessary to mention because we have different and conflicting ideas.

It happens that I agree with the current state of how it is in Drupal. So basically you're going to have to change my opinion about the matter by making a compelling argument. I'm actually the javascript maintainer so if I don't agree with the change and since there are so few people caring about JS at all, it most likely won't go through (that is because there will not be enough people opposing me to commit the change regardless of my opinion on the matter).

I'm not saying I will make everything I can to block this issue. I'm just explaining how it usually works. If there are good arguments I will change my mind.

I get it about the type, I just wanted to highlight that if we're starting with this one, why not put some others that could save time as well and if that's the case, where do we stop?

And you know what, on my AMD issue #1542344: Use AMD for JS architecture, I'll end up adding an option to wrap the code in a function call an that will make jQuery available with $ by default without adding it to the global scope. So basically the end result you want will be implemented, in a slightly different (and cleaner) way. Obviously that will not be the recommended way to do things, it'll just be a possible and i-dont-want-to-deal-with-that way of adding javascript.

@nod_:

It happens that I agree with the current state of how it is in Drupal. So basically you're going to have to change my opinion about the matter by making a compelling argument. I'm actually the javascript maintainer so if I don't agree with the change and since there are so few people caring about JS at all, it most likely won't go through (that is because there will not be enough people opposing me to commit the change regardless of my opinion on the matter).

As of now, the agreed-on and executed practice as well as our (non-existing) definition of subsystem/component maintainers in MAINTAINERS.txt is different; subsystem maintainers generally try to provide vision and direction, and help core contributors to understand complex problem spaces affecting the subsystem. Unless being involved already, we're trying to pull them into issues in which their knowledge and expertise is needed. It surely helps to have the subsystem maintainers on board for a certain proposal. However, it does not mean that anyone has any more say or power that expressively allows to "block" changes from happening. Subsystem maintainers may disagree with a proposal, but a change proposal can only get blocked on pure technical merits, not personal opinions or disagreements. Therefore, in general, we keep such statements out of the issue queue.

I'm providing vision and guidance, I'm saying that right now this is not a good idea because there is an overall plan to address this issue.

@nod_:

So basically you're going to have to change my opinion about the matter by making a compelling argument. I'm actually the javascript maintainer so if I don't agree with the change and since there are so few people caring about JS at all, it most likely won't go through

I'm also a little perplexed at this kind of talk but I can only echo sun's sentiment in #46

I get it about the type, I just wanted to highlight that if we're starting with this one, why not put some others that could save time as well and if that's the case, where do we stop?

I didn't really have the sense that options for type in drupal_add_js were running rampantly out of control, so it seems like the "where will it end" argument is a little preemptive to me. We should add options for things that are very commonly done, get lots of use, and save developers time, and that's where it stops. I don't think there are a lot of other proposals out there like this nor do I think there will be in the future, so it seems like a non-issue - but correct me if I'm wrong.

I'm saying that right now this is not a good idea because there is an overall plan to address this issue.

Well why didn't you say so in the first place? I took a look at the AMD issue and it seems like you have some momentum there, overall JS management will be taking some steps forward, and this issue is taken into consideration, so carry on. I don't think I have the finger strength to type anymore comments on this issue anyway.

Re-closing.

@justindodge - I think an important thing to note is the use of closures and the module pattern. Just passing in jQuery (like a lot of the Drupal scripts do) while not passing in other global dependencies isn't a good thing.

There is a great article on the module pattern at http://www.adequatelygood.com/2010/3/JavaScript-Module-Pattern-In-Depth. You should take a read.

If this were something simple, without a lot of options, or a bunch of opinions I would be all for automating it. Unfortunately that is not the case. It's complex.

tweak