payload: {"action":"opened","issue":{"url":"https://api.github.com/repos/rollup/rollup/issues/3062","repository_url":"https://api.github.com/repos/rollup/rollup","labels_url":"https://api.github.com/repos/rollup/rollup/issues/3062/labels{/name}","comments_url":"https://api.github.com/repos/rollup/rollup/issues/3062/comments","events_url":"https://api.github.com/repos/rollup/rollup/issues/3062/events","html_url":"https://github.com/rollup/rollup/issues/3062","id":481459978,"node_id":"MDU6SXNzdWU0ODE0NTk5Nzg=","number":3062,"title":"Option to turn off the \"avoiding the waterfall\" feature","user":{"login":"philipwalton","id":326742,"node_id":"MDQ6VXNlcjMyNjc0Mg==","avatar_url":"https://avatars1.githubusercontent.com/u/326742?v=4","gravatar_id":"","url":"https://api.github.com/users/philipwalton","html_url":"https://github.com/philipwalton","followers_url":"https://api.github.com/users/philipwalton/followers","following_url":"https://api.github.com/users/philipwalton/following{/other_user}","gists_url":"https://api.github.com/users/philipwalton/gists{/gist_id}","starred_url":"https://api.github.com/users/philipwalton/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/philipwalton/subscriptions","organizations_url":"https://api.github.com/users/philipwalton/orgs","repos_url":"https://api.github.com/users/philipwalton/repos","events_url":"https://api.github.com/users/philipwalton/events{/privacy}","received_events_url":"https://api.github.com/users/philipwalton/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":0,"created_at":"2019-08-16T06:21:52Z","updated_at":"2019-08-16T06:21:52Z","closed_at":null,"author_association":"NONE","body":"<!--\r\n  ⚡️ katchow! We 💛 issues.\r\n\r\n  Please - do not - remove this template.\r\n  Please - do not - skip or remove parts of this template.\r\n  Or your issue may be closed.\r\n\r\n  👉🏽 Need help or tech support? Please don't open an issue!\r\n  Head to https://gitter.im/rollup/rollup or https://stackoverflow.com/questions/tagged/rollupjs\r\n\r\n  ❤️ Rollup? Please consider supporting our collective:\r\n  👉 https://opencollective.com/rollup/donate\r\n-->\r\n\r\n### Feature Use Case\r\n\r\nI recently started noticing a lot of import statements in my built modules that don't actually import any symbols. Here's an example:\r\n\r\n```js\r\nimport './core-js-4d767783.mjs';\r\nimport { p as polyfillDynamicImport } from './polyfillDynamicImport-171c7873.mjs';\r\nimport './object-assign-d3be3a6c.mjs';\r\nimport './react-1f5f6245.mjs';\r\nimport './date-fns-466f94c0.mjs';\r\nimport './highlight.js-2ff46463.mjs';\r\nimport './style-inject-d8a06a3d.mjs';\r\nimport './CodeBlock-a5cc5a9f.mjs';\r\nimport './timeOrigin-692e90ef.mjs';\r\nimport './App-dc9eaee3.mjs';\r\nimport { m as main } from './main-eb2319cc.mjs';\r\n```\r\n\r\nWhen I started looking into why, I realized this is actually intended to be a feature: [\"avoiding the waterfall\"](https://levelup.gitconnected.com/code-splitting-for-libraries-bundling-for-npm-with-rollup-1-0-2522c7437697#5a36)\r\n\r\nAt first I thought this was really cool, but then, based on some stuff I learned from some Chrome engineers who implemented modules, I realized this probably isn't a good practice. What developers should really be using to avoid the waterfall is [`modulepreload`](https://developers.google.com/web/updates/2017/12/modulepreload) (which works for both static and dynamic imports, via [`Link` headers](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Link)).\r\n\r\nThe problem with using \"real\" imports to preload a bunch of modules is, when fetching them, the spec says to run the [`#internal-module-script-graph-fetching-procedure`](https://html.spec.whatwg.org/multipage/webappapis.html#internal-module-script-graph-fetching-procedure) algorithm, and when using `modulepreload`, the spec says to run the [`#fetch-a-single-module-script`](https://html.spec.whatwg.org/multipage/webappapis.html#fetch-a-single-module-script) algorithm. The former algorithm will also fetch sub-dependencies, while the later algorithm will only fetch the single module.\r\n\r\nThe problem with running the [`#internal-module-script-graph-fetching-procedure`](https://html.spec.whatwg.org/multipage/webappapis.html#internal-module-script-graph-fetching-procedure) algorithm on a bunch of modules that likely have common sub-dependencies is you'll end up processing many of those sub-dependencies more than once, so the processing time ends up being O(n^2) rather than O(n) for `modulepreload`.\r\n\r\n### Feature Proposal\r\n\r\nWhile the current approach is probably better than a completely unoptimized load (without `modulepreload`), it's worse than an optimized load (because the file sizes are larger than they need to be).\r\n\r\nAs a result, I propose Rollup add an option to turn off this feature (it's something `modulepreload` plugins could turn off automatically for users of their plugins).\r\n\r\nAs long as `ChunkInfo.imports` contains the complete (deep) graph of all imports needed for a particular entry chunk, it should be easy enough for developers to generate their own `modulepreload` lists. However, if removing the imports-as-modulepreload statements from the final output also means they're removed from the `ChunkInfo.imports` object, I'd _also_ suggest adding another property (perhaps `importsDeep`) to the `ChunkInfo` object, so it continues to be easy to generate a `modulepreload` list from the `bundle` object.\r\n\r\nWhat do you think?\r\n"}}
other: {"actor":{"display_login":"philipwalton"}}