Closed joelambert closed 8 years ago
No problem, thanks for the explanation. Understand your rationale!
Unless its a super edge case to use the plugin inside a worker perhaps the above example could make its way into the docs so others don't do what we did?
I don't think it's super edge-casey. :) I'm curious to know how you approached this problem to even run into this issue, though; most devs I know are already using bundlers (including for web worker code), but maybe my circle of colleagues is very narrow and so I don't understand others' experiences. Were you indeed trying to use importScripts()
?
We were using importScripts()
yes. The project actually already has a Gulp based build process which includes Browserify (and Babel for ES6 modules etc) but as our Worker is only a few lines of code and is very standalone we opted to just use it unprocessed.
It wouldn't take much to rework our Worker code to use Browserify, it just felt like an unnecessary complication for such a small piece of code.
Thanks for the PR! :smiley: Since this only applies to the case of
importScripts()
, though, and since that is quasi-deprecated in favor of ES6 modules, I would be more comfortable saying that you should use Browserify/Webpack/Rollup instead to bundle your JS, and then load the plugin that way. E.g.:The whole
window.PouchDB
auto-magic was kinda designed for people who are more comfortable with<script>
tags, not people who are advanced enough to feel adept with workers. I'm also worried about creating a precedent where this trick would be expected to be supported by all ~50 PouchDB plugins (including the ~30 written by me :sweat_smile:), and I would rather avoid that. Thanks for understanding!