Use ES6 & WebPack? Bring Back UMD!

[mAAdhaTTah]

You said to open a ticket if I needed UMD, so here I am :).

We're looking at integrating what-input for helping with some accessibility issues we're having. However, we're developing everything internally in ES6, loading via modules, and compiling with webpack. Given that, I really dislike the idea of importing something that adds a global, as we've already had problems with these sorts of "implicit" dependencies on the global scope that we weren't aware of and caused issues, and would make it difficult for us long-term to to maintain.

I don't know how open you are to changes in your process, but I do know webpack can handle compiling to umd so that may help eliminate the overhead of maintaining the UMD wrapper yourself, deferring it to webpack instead.

And since we're using ES6, the static analysis of ES6 modules has been very helpful for us, so might also suggest updating to use ES6 modules as well so ES6 consumers like us can use the module rather than the compiled build.

I'm not the type to drop in on an OS project and suggest a bunch of work and walk away, so I will also say that if these are changes you might be open to, I'd be willing to work on and open a PR to implement them as well. That said, you're still going to end up being the one to maintain this long-term, so it's up to you.

Let me know what you think!

[ten1seven]

Hi James,

Thanks for adding the ticket and offering to help! I pulled the UMD wrapper out of frustration in trying to find something workable across different situations. Since this whole thing started with Foundation transpiling all JavaScript through Babel (why oh why would they do that to vendor scripts), how would you recommend supporting ES6 and ES5? Two versions?

[mAAdhaTTah]

Here's what I'm thinking for supporting both:

Convert the library to ES6 code and save it as src/index.js. It will export default the main object. Then you add "jsnext:main": "src/index.js" to the package.json. While it's not exactly a "standard", it is commonly used for that purpose, and even if the user's build tool doesn't use it by default, both browserify and webpack allow you to configure additional mains to use.

Will the ES6 code in place, you can compile it to an ES5-compliant UMD file in dist/index.js. Both webpack and browserify have library or standalone mode where they will compile and emit a UMD-library. That build step can be integrated into your gulp build or just handled via npm scripts.

Going forward, you would just need to maintain the ES6 src/index.js file and let the build process handle the UMD wrapping. If you still want to support bower, you would need to commit the dist/index.js file to the repo, since bower is basically just a thin wrapper around GitHub, and fortunately, since this is a browser-only plugin, we don't have to worry about node builds either.

I think that should cover it. If this sounds good to you, let me know whether you'd prefer browserify or webpack (or some other tool) and I'll see about pulling this together over the next few days.

[ten1seven]

Sounds good! I'm more familiar with Browserify but Webpack had become so popular it's probably worth using and the implementation should be simple enough that it's be a good opportunity for me to pick it up 😄

I just committed some updates with a version bump to 2.1.0 that consolidates the Gulp tasks into a single file and, more notably, changes the input switching behavior when interacting with form elements.

[ten1seven]

Hi @mAAdhaTTah! Have you had any time to make progress on this? I'm having other people ask about this as well.

[mAAdhaTTah]

I have not, as the project that involves this change got delayed. If you need it, I'll see if I can take a pass at it today.

[ten1seven]

Thanks for the update! No rush unless you have the time.