-
-
Notifications
You must be signed in to change notification settings - Fork 9
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Differing default exports #83
Comments
This is exactly the standard interop problem. This edge case applies only for modules that export both an jspm has gone the other way to Webpack and RollupJS on this one specific edge case to instead follow Node.js semantics which are more well-defined. You can read more about the strict Node.js interop semantics here - https://nodejs.org/dist/latest-v15.x/docs/api/esm.html#esm_commonjs_namespaces. If you want to write you import in a way that works with any bundler for this edge case, write: import _nearest from "https://jspm.dev/@turf/nearest-point-on-line";
const nearest = _nearest.default || _nearest; |
ok. I did notice that the Thanks for the prompt response. |
Sure, and if you'd like a beta invite just ping me. |
import _nearest from "https://jspm.dev/@turf/nearest-point-on-line";
const nearest = _nearest.default || _nearest; That's not an elegant solution as it pushes the burden onto the consumer of the module. What would be the recommended way to fix this on the module side? In my case, it's https://github.com/staltz/xstream/blob/v11.14.0/dist/xstream.js which is apparently generated by https://www.npmjs.com/package/babel-plugin-transform-es2015-modules-umd |
The If you are interested in why this is the case, read the interop issue here - rollup/plugins#635. |
I'm using several functions from Turfjs, a library of functions for manipulating GeoJSON files. With most of them, I can just do, for example:
import lineSplit from "https://jspm.dev/@turf/line-split";
and then
lineSplit(...)
but with
import nearest from "https://jspm.dev/@turf/nearest-point-on-line";
I cannot do
nearest(...)
, but have to donearest.default(...)
.Is this expected behaviour, and if so why?
The text was updated successfully, but these errors were encountered: