{"action":"created","issue":{"url":"https://api.github.com/repos/webpack/webpack/issues/6472","repository_url":"https://api.github.com/repos/webpack/webpack","labels_url":"https://api.github.com/repos/webpack/webpack/issues/6472/labels{/name}","comments_url":"https://api.github.com/repos/webpack/webpack/issues/6472/comments","events_url":"https://api.github.com/repos/webpack/webpack/issues/6472/events","html_url":"https://github.com/webpack/webpack/issues/6472","id":296561653,"number":6472,"title":"The case for Workers","user":{"login":"surma","id":234957,"avatar_url":"https://avatars1.githubusercontent.com/u/234957?v=4","gravatar_id":"","url":"https://api.github.com/users/surma","html_url":"https://github.com/surma","followers_url":"https://api.github.com/users/surma/followers","following_url":"https://api.github.com/users/surma/following{/other_user}","gists_url":"https://api.github.com/users/surma/gists{/gist_id}","starred_url":"https://api.github.com/users/surma/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/surma/subscriptions","organizations_url":"https://api.github.com/users/surma/orgs","repos_url":"https://api.github.com/users/surma/repos","events_url":"https://api.github.com/users/surma/events{/privacy}","received_events_url":"https://api.github.com/users/surma/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":1,"created_at":"2018-02-12T23:28:17Z","updated_at":"2018-02-13T12:30:58Z","closed_at":null,"author_association":"NONE","body":"<!-- Please don't delete this template or we'll close your issue -->\r\n<!-- Before creating an issue please make sure you are using the latest version of webpack. -->\r\n<!-- Also consider trying the webpack@beta version, maybe it's already fixed. -->\r\n\r\n**Do you want to request a *feature* or report a *bug*?**\r\n\r\nFeature! 🎉 \r\n\r\n<!-- Please ask questions on StackOverflow or the webpack Gitter (https://gitter.im/webpack/webpack). -->\r\n<!-- Issues which contain questions or support requests will be closed. -->\r\n\r\n**What is the current behavior?**\r\n\r\n(This is gonna be a bit longer.)\r\n\r\nLet’s imagine working on a project using [WebWorkers]. Let’s say I am using this great new shiny library [Comlink]. It’s needed by both `main.js` and `worker.js` as Comlink is an abstraction over `postMessage`. Of course both `main.js` and `worker.js` have other dependencies besides Comlink.\r\n\r\n![dependencies](https://user-images.githubusercontent.com/234957/36124715-048b2918-1049-11e8-8f4f-815b3a5e4148.png)\r\n\r\n(You might already be able to tell where I’m going with this)\r\n\r\n**Attempt 1: Entry points**\r\n\r\nListing both `worker.js` and `main.js` as entry points doesn’t yield the expected results as all static imports will be inlined. Comlink will be (down)loaded twice. The semantics of entry points are that only one entry point will be loaded at a time. In the context of my example, though, two entry points are loaded in parallel.\r\n\r\n![suboptimalchunk](https://user-images.githubusercontent.com/234957/36125110-a067fa04-104a-11e8-9f56-704ca86b76d8.png)\r\n\r\n**Attempt 2: Dynamic loading**\r\n\r\nI tried some hackery with `import()`, but the problem is that WebPack (rightly) assumes that there’s is a global registry of loaded modules. `worker.js`, however, runs in a different realm and has a separate global scope to `main.js`\r\n\r\n**Workaround: Force a common chunk**\r\n\r\nMy current workaround is to use the entry point approach and manually maintain a list of shared modules that need to be put in a separate chunk using `CommonChunksPlugin`:\r\n\r\n```js\r\nmodule.exports = {\r\n  entry: {\r\n    main: './src/main.js',\r\n    worker: './src/worker.js',\r\n  },\r\n  output: {\r\n    filename: '[name].js',\r\n  },\r\n  plugins: [\r\n    // Force comlink into its own bundle\r\n    new webpack.optimize.CommonsChunkPlugin({\r\n      name: 'comlink',\r\n      minChunks: 2,\r\n    }),\r\n  ],\r\n};\r\n```\r\n\r\n\r\n**If the current behavior is a bug, please provide the steps to reproduce.**\r\n\r\n<!-- A great way to do this is to provide your configuration via a GitHub gist. -->\r\n<!-- Best provide a minimal reproduceable repo -->\r\n<!-- If your issue is caused by a plugin or loader file the issue on the plugin/loader repo -->\r\n\r\n**What is the expected behavior?**\r\n\r\nUnder the assumption that there’s good caching headers, the optimal behavior is to put Comlink in it’s own chunk (or a chunk for shared modules) so it’s only downloaded once. The second request by the worker will hit the HTTP cache and re-use the already downloaded shared chunk.\r\n\r\n![optimalchunk](https://user-images.githubusercontent.com/234957/36125059-67bd99d4-104a-11e8-8e92-a2005b23a26a.png)\r\n\r\n**API**\r\n\r\nI’m not sure what the API for this would look like. This API would not only be useful for workers, but also for pages that load another entry point in an iframe (although, tbh, I struggle to find a good example for this 🤷‍♂️ )\r\n\r\n I think the most straight-forward way would to add a `realmEndpoints` (name pending lol) to the webpack config which lists entry points that can be loaded in parallel to _one_ of the main entry points.\r\n\r\nWhat do y’all think? API suggestions/corrections? Am I just holding it wrong?\r\n\r\n\r\n\r\n\r\n**If this is a feature request, what is motivation or use case for changing the behavior?**\r\n\r\n**Please mention other relevant information such as the browser version, Node.js version, webpack version and Operating System.**\r\n\r\n[WebWorkers]: https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers_API\r\n[Comlink]: https://github.com/GoogleChromeLabs/comlink\r\n"},"comment":{"url":"https://api.github.com/repos/webpack/webpack/issues/comments/365253169","html_url":"https://github.com/webpack/webpack/issues/6472#issuecomment-365253169","issue_url":"https://api.github.com/repos/webpack/webpack/issues/6472","id":365253169,"user":{"login":"sokra","id":1365881,"avatar_url":"https://avatars0.githubusercontent.com/u/1365881?v=4","gravatar_id":"","url":"https://api.github.com/users/sokra","html_url":"https://github.com/sokra","followers_url":"https://api.github.com/users/sokra/followers","following_url":"https://api.github.com/users/sokra/following{/other_user}","gists_url":"https://api.github.com/users/sokra/gists{/gist_id}","starred_url":"https://api.github.com/users/sokra/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/sokra/subscriptions","organizations_url":"https://api.github.com/users/sokra/orgs","repos_url":"https://api.github.com/users/sokra/repos","events_url":"https://api.github.com/users/sokra/events{/privacy}","received_events_url":"https://api.github.com/users/sokra/received_events","type":"User","site_admin":false},"created_at":"2018-02-13T12:30:58Z","updated_at":"2018-02-13T12:30:58Z","author_association":"OWNER","body":"It may be possible to create a new agnostic target in which chunks have the same format, than something like this could work.\r\n\r\n---\r\n\r\nFor on-demand-loading:\r\n\r\nWhile in web target loading chunk in parallel is easily possible via `<script>` tags, `importScripts` in webworker context is sync and don't allow parallel loading. We would need to use `fetch` instead, which has cross-origin limitation, but I assume this won't be a problem in webworkers.\r\n\r\nFor initial loading:\r\n\r\nweb target support multiple initial chunks via multiple `<script>` tags in HTML. `new Worker()` only supports a single argument. So it's difficult to startup a worker with multiple parallel initial chunks.\r\n\r\nIt may be possible to solve these challenges with a ServiceWorker doing the parallel requests and concatenation the responses..."}}
{"actor":{"display_login":"sokra"}}