Adding UMD support

[jwilsson]

As we started discussing a bit in #11, it would be really nice to add UMD support but it does bring some extra bytes and since we want to keep it as small as possible I were thinking that we should look into a possibility to do a separate/conditional build with UMD support.

I found eduardolundgren/gulp-umd after a quick search, I haven't looked at it any closer but it sounds like something we could use.

Thoughts?

[TrySound]

@jwilsson There is nothing to export. So UMD can't give us any flexibility. The only problem of that issue is too strict linting. For multiple modules I'd like to suggest rollup. Here is example

[rodneyrehm]

I think it would be fine to be able to load the main DOMTokenList utility separately, as this is only required in non-browser environments (WebWorker, Node.js).

[jwilsson]

@rodneyrehm May I ask about your use case? I don't think it's possible to use DOMTokenList on its own or am I missing something in the spec?

[rodneyrehm]

@rodneyrehm May I ask about your use case?

As far as I see it, DOMTokenList is the perfect base to interface with ID reference lists like aria-describedby (among other similar properties).

I don't think it's possible to use DOMTokenList on its own […]

I don't see how you can't use it to construct strings of tokens, even outside of the DOM. After all, DOMTokenList is nothing but an elegant interface for mutating a string in a particular way.

[jwilsson]

@rodneyrehm Sorry for the late reply.

Have you found a way to use DOMTokenList outside the DOM or on an arbitrary attribute? I can't seem to find a way and as I'm sure you understand, we'd rather not add any functionality which doesn't fit the spec (except UMD support).

[rodneyrehm]

Have you found a way to use DOMTokenList outside the DOM or on an arbitrary attribute?

Sure, see this example. This doesn't work with the browser's DOMTokenList, as it'll throw Uncaught TypeError: Illegal constructor, but that's exactly the reason to use your polyfill instead, isn't it? As you can see I did not add any functionality, I merely replaced window.DOMTokenList = DOMTokenList with return DOMTokenList as you'd do for UMD anyway.

At this time, your polyfill allows to run outside of the browser, too (example without dom):

var data = {
  gustav: ''
};
var x = new _DOMTokenList(data, 'gustav');
x.add('one');
x.add('two');
alert(data.gustav);

Again, I haven't added any functionality.

[jwilsson]

Alright @rodneyrehm, lets do it! I'm thinking we should go with the two separate builds, one "regular" like today and one with UMD support using eduardolundgren/gulp-umd. Would you be interested in taking a look at it? Otherwise, I'll have some time later this week.

On another note, I hope I didn't came off as reluctant. I just don't want to introduce too many deviations from the spec :)

[rodneyrehm]

Would you be interested in taking a look at it? Otherwise, I'll have some time later this week.

I'm not in a hurry and have no idea of gulp ;)
That said, I don't really know what you need gulp or gulp-UMD for anyway. Here's the UMD thing I would've done

On another note, I hope I didn't came off as reluctant. I just don't want to introduce too many deviations from the spec :)

nope, everything's good! :)

[jwilsson]

@rodneyrehm Sorry for the delay.

Could you check the new UMD build and see if it works?

[rodneyrehm]

We - and by that I mean me - may have been a bit short sighted. Say I wanted to use both, the full shim and DOMTokenList in the same app, I'd currently be loading DOMTokenList twice. The only way to avoid that is if all the modules, including the file that aggregates/concatenates the source files, are exposed individually. I've only been thinking about either using the shim or the DOMTokenList exclusively in separate context - but I'd actually need to use both in the same context.

Since you haven't been exposing modules up to now, you can't break compatibility by anything you do, so long dist/domtokenlist.js still works without a module loader.

Since all the files in src are valid CommonJS at this point (only DOMTokenList.js actually exports anything), you could add the following index.js and use browserify's --standalone option to build an UMD bundle of everything:

// src/index.js -> dist/domtokenlist.js
require('./DOMTokenList-newest.js');
require('./DOMTokenList.js');
require('./classList.js');
require('./relList.js ');

This way, anyone with a CommonJS setup would be able to load src/index.js and pretty much get the same as dist/domtokenlist.js provides, but also being able to load src/DOMTokenList.js separately.

Considering that anyone who wants to do this, is able to do that index.js trick themselves, it is not absolutely necessary for your project to provide this.

[jwilsson]

Hi @rodneyrehm,
Sorry for the late reply.

But I'm thinking that perhaps we should leave it at that then unless someone else is interested in making a proper UMD build of everything either in this project or as a fork of it.

Since it's possible, as you say, to build a UMD bundle it using browserify (and other similar tools too, I presume) then I think that's good enough for now at least.

I'll reopen and add a "Help wanted" label in case someone finds it and wants to take a stab at it.