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 src/css/var/.

I see, though, that some other modules from core are not following the same principle, e.g. src/core/access.js should be a variable as well.

cc @timmywil

Why not?

Didn't you answer your own question with -

I see, though, that some other modules from core are not following the same principle, e.g. src/core/access.js should be a variable as well.

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 var-modules was created by @timmywil to save size in the built file. Refactoring your PR in this way saves 2 bytes.

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?

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