New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Core: do not expose second argument of the jQuery.globalEval
#2718
Conversation
This should be a variable, i.e. it should lie in /core/var/. |
I don't think so @mzgol |
Why not? A module that exports a single thing and doesn't have side effects should be a variable. Look at I see, though, that some other modules from cc @timmywil |
Didn't you answer your own question with -
There is a lot of modules like that. I don't think we should impose additional restrictions on the contributions process. |
@markelog From what I remember this was not an arbitrary restriction, the concept of I thought it was going to bring bigger gains, though... So, out of curiosity I applied it to other similar modules and... I got back to the size from this PR (i.e. I lost 2 bytes). @timmywil, since those var-modules don't seem to save size as much as I thought (or not at all sometimes), could you clarify what's their purpose? Because, as @markelog pointed out, currently the decision whether to create a var-module or a regular one seems completely random looking at all the files. |
The point of the var modules is to translate... // File var/arr.js
define( function() {
return [];
} ); to var arr = []; This is necessary whether the size gains are minor or not. For functions, though, the use of this translation is more subjective. I've mainly used var modules for smaller, one- to two-line, functions. I don't think we need to do that here. |
I know it might be sound... ahhh, weird :-), but should we document that? |
Meh. |
We could stick a note about it in CONTRIBUTING.md. |
Yeah, my thought exactly, not on contribute.jquery.com or anything like that |
Ref jquery/api.jquery.com#831