Flubber performs differently when loaded via webpack/babel. about flubber HOT 4 CLOSED

Closed with 525ce54, which always checks for browser API first before falling back to svg-path-properties.

from flubber.

This does seem like a transpilation issue of some kind - I can reproduce the issue with CRA but if I copy the flubber repo into src/ instead, and import it directly, e.g.:

import { interpolate } from "./flubber/index.js"

I can get the desired effect. I'm not sure where exactly the transpiler is going awry, I'll try to look into it more later.

from flubber.

I think there are two related issues at play here:

1. The particular path strings you included get very different results when measuring them with the browser's native SVG .getPointAtLength vs. with the svg-path-properties library. If I force Flubber to use the browser's measurement, it looks fine. svg-path-properties is approximating the curves in such a way that the calculated points are far enough off the mark to produce this weird result with this particular shape.

2. Flubber includes the following block:

  if (typeof module !== "undefined" && module.exports) {
    return svgPathProperties(d);
  } else {
    var svg = window.document.createElementNS("http://www.w3.org/2000/svg", "svg"),
      path = window.document.createElementNS("http://www.w3.org/2000/svg", "path");

    path.setAttributeNS(null, "d", d);

    return path;
  }

the purpose of which is to use the browser's native SVG methods when running in a browser, and otherwise to use the svg-path-properties library to measure the path string's length and points along it when running in Node.

Something about how Webpack wraps modules into its bundle is causing Flubber to think it's not in a browser and execute that block instead of skipping it, presumably module.exports is getting shimmed in somehow.

The ideal solution for this would be for me to produce a different build for the browser field in package.json that doesn't use svg-path-properties at all, and then maybe Webpack would rely on that instead. But in the meantime, it seems like the fix here would be to update the Webpack config in such a way that it actually bundles the ES6 modules directly rather than using the rolled up flubber.min.js.

from flubber.

Thanks for the fix!

from flubber.