version 5.1.1 contains an arrow function about tabbable HOT 4 CLOSED

@khamiltonuk Thanks for filing this issue! It ended-up being brought-up over on focus-trap/focus-trap#173 and we had a discussion there.

Bringing that over to here now:

Webpack can be configured to work around this. The issue is you're wanting to use ESM as a modern module system, but still expecting to have old browser-compatible code inside those modules, and not wanting to transpile any third-party modules. Is that correct (just trying to understand the needs)?

It feels strange to have diverging targets in the same bundle: ES modules (which is technically ES6) and ES5 JS. But I admit I see the same issue in my bundles that reference focus-trap if I set my Babel target to ie: "11" (I end-up with the same issue with the arrow function @khamiltonuk pointed out earlier).

Looks like this is a problem for a lot of libraries, and Webpack is keeping its position on prioritizing module over main for 3 years now: webpack/webpack#5756 (still open)

A lot of packages seem to have solved this by adding a browser entry to their package.json (because Webpack's default order is mainFields: ['browser', 'module', 'main']), which is something we could do with focus-trap and tabbable.

Apparently, this is the browser field spec, but it doesn't really get into specifics about the nature of the referenced files.

Still, given its name "browser", it feels like it should point to the UMD build.

Thoughts?

👉 I just tried this locally with tabbable's package.json having "browser: dist/index.umd.js" (with Webpack) and the resulting bundle that includes tabbable look nice. Webpack took the right UMD "path" for CJS and plopped the result right into the bundle:

}, function(module, exports, __webpack_require__) {
  !function(exports) {
    "use strict";
    var candidateSelectors = [ "input", "select", "textarea", "a[href]", "button", "[tabindex]", "audio[controls]", "video[controls]", '[contenteditable]:not([contenteditable="false"])', "details>summary" ], candidateSelector = candidateSelectors.join(","), matches = "undefined" == typeof Element ? function() {} : Element.prototype.matches || Element.prototype.msMatchesSelector || Element.prototype.webkitMatchesSelector;
    function tabbable(el, options) {
      var regularTabbables = [], orderedTabbables = [];
      return getCandidates(el, (options = options || {}).includeContainer, isNodeMatchingSelectorTabbable).forEach((function(candidate, i) {
        var candidateTabindex = getTabindex(candidate);
        0 === candidateTabindex ? regularTabbables.push(candidate) : orderedTabbables.push({
          documentOrder: i,
          tabIndex: candidateTabindex,
          node: candidate
        });
      })), orderedTabbables.sort(sortOrderedTabbables).map((function(a) {           // <- NO ARROW!
        return a.node;
      })).concat(regularTabbables);
    }

    ...

    exports.focusable = focusable, exports.isFocusable = isFocusable, exports.isTabbable = isTabbable, 
    exports.tabbable = tabbable, Object.defineProperty(exports, "__esModule", {
      value: !0
    });
  }(exports);

Based on this, I believe the correct solution here is not to transpile ESM into ES5 while still keeping import/export statements that are part of the language syntax of ES6 (diverging targets for the same build), but rather to simply add the browser: ./dist/index.umd.js entry to package.json.

from tabbable.

@all-contributors add @khamiltonuk for bug

from tabbable.

@stefcameron

I've put up a pull request to add @khamiltonuk! 🎉

from tabbable.

OK, folks, this is hopefully finally fixed in [email protected]. Please LMK if there's still an issue, and my apologies for the hiccup!

from tabbable.