-
-
Notifications
You must be signed in to change notification settings - Fork 46
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
Add compiled dist version to npm package? #39
Comments
Hey, nice work on this! I stumbled upon ResizeObserver and your polyfill just recently. Planning on using it to detect element height changes. I'd say yes, add to npm packages. |
Hey @marval2, thanks, that's great to hear! It's good to have your input on this. Currently I have concerns over polyfilling the global scope as it becomes too easy to just throw it in and forget about it. This means the native RO could be overridden, even when it's available to use. Saying that, I'm still leaning towards adding it in. I also think it's required and there are still options to only load the polyfill, if RO isn't available. |
Some options for output directory name... dir: <script src="@juggle/resize-observer/<dir>/resize-observer.js"></script> |
I'd say add it in, it won't hurt and as you said there are other options to load. My vote goes for dist |
Just found out about the whole ResizeObserver thing and your polyfill, I tried it and it's great, definitely gonna use it in the near future. I was a bit surprised to see that IE11 is supported while there isn't any ES5 version of the library shipped with the package (got a syntax error while loading my app on IE, that was weird). Anyway, unless there is some feature that depends on ES2015 (and since it works on IE, I doubt it), you should simply switch your Typescript target to ES5 so that your consumers (like me) won't need to configure specifically their bundler or whatever to use the library. A bundled version of the library (in ES5 too) could be useful for a quick import in a project that doesn't use a bundler. I don't think it's reasonable that any version of the library polyfills the global ResizeObserver by default, especially since your goal is to be as close as possible to the spec, instead of say the Chrome implementation that might lag behind it. The spec doesn't look mature enough for this. |
Hey @JabX, that's great! I agree that the configuration to get it working in IE isn't the easiest and should be documented better (#47). The reason for not releasing in ES5 is because the library becomes bloated and slower in browsers which support ES2015. It's also nicer to import ES modules in modern code, so I'd like to keep the library this way. The "dist" version would be a quick-win drop and go file that would polyfill the global The latest spec is definitely not mature enough, which is why I'm holding off on #41. The reason for adding in different box sizes is because it enabled live trialing of the feature and didn't affect the original API. |
You could still target ES5 but with ESNext modules, this is what I usually do when building libraries, as it keeps all the module benefits while not requiring any particular packaging config on the customer side. |
I think supplying a UMD module alongside an ESM module, could help to fix this issue. I don't think releasing a globally polluting bundle is the right way to go. UMD:
ESM:
Pika is currently serving ESM and UMD bundles 🎉 https://cdn.pika.dev/@juggle/resize-observer/v2 |
I just tried to use the library in our Meteor project and it fails because Meteor only transpiles app code, not libraries. It's the only library I've had this issue with. I suggest releasing a |
Thanks @alejandroiglesias and sorry it's not currently working for you. I just realised my previous comment was a bit confusing, so I've reworded it a bit. The plan is pretty much exactly as you said, to keep the current There is NO plan to add a drop-in dist package, which always overrides the global scope. |
To be clear the {
// Transpiled ES5 module (UMD)
"main": "./umd/ResizeObserver.js",
// Original module (ESM)
"module": "./lib/ResizeObserver.js",
...
} |
@marval2 @JabX @alejandroiglesias Ok, so actually playing around with this in different bundlers and real-life situations -> umd is basically a pain in some instances and isn't really needed anyway. Must have being 😴 when looking at this before. @JabX after some ☕️ I'm thinking of using your idea 👍 Would love some feedback on the PR for this #63 Thanks! |
|
Wondering whether to add a compiled ES5 version of the library which polyfills the global
ResizeObserver
on thewindow
.This makes it easier to integrate into older projects.
Would this be helpful?
The text was updated successfully, but these errors were encountered: