{"action":"created","issue":{"url":"https://api.github.com/repos/rollup/rollup/issues/2092","repository_url":"https://api.github.com/repos/rollup/rollup","labels_url":"https://api.github.com/repos/rollup/rollup/issues/2092/labels{/name}","comments_url":"https://api.github.com/repos/rollup/rollup/issues/2092/comments","events_url":"https://api.github.com/repos/rollup/rollup/issues/2092/events","html_url":"https://github.com/rollup/rollup/issues/2092","id":309232074,"number":2092,"title":"[Roadmap] The future of experimentalCodeSplitting and experimentalDynamicImports","user":{"login":"lukastaegert","id":12949268,"avatar_url":"https://avatars2.githubusercontent.com/u/12949268?v=4","gravatar_id":"","url":"https://api.github.com/users/lukastaegert","html_url":"https://github.com/lukastaegert","followers_url":"https://api.github.com/users/lukastaegert/followers","following_url":"https://api.github.com/users/lukastaegert/following{/other_user}","gists_url":"https://api.github.com/users/lukastaegert/gists{/gist_id}","starred_url":"https://api.github.com/users/lukastaegert/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/lukastaegert/subscriptions","organizations_url":"https://api.github.com/users/lukastaegert/orgs","repos_url":"https://api.github.com/users/lukastaegert/repos","events_url":"https://api.github.com/users/lukastaegert/events{/privacy}","received_events_url":"https://api.github.com/users/lukastaegert/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":22,"created_at":"2018-03-28T06:04:23Z","updated_at":"2018-05-13T09:51:40Z","closed_at":null,"author_association":"CONTRIBUTOR","body":"This is a collection of ideas what should happen before we deprecate these two `experimental` options. Of course everything here is open to discussion. This description should be updated accordingly including issues tracking individual steps.\r\n\r\n### `experimentalDynamicImports`\r\nAt the moment, this option controls both the parseability of dynamic imports as well as various code snippets dealing with them. As this is still only a stage-3 feature, we should probably not get rid of this option just yet. Nevertheless, the following might make sense:\r\n- [ ] `experimentalDynamicImports` should only control if the corresponding acorn plugin is added but all other checks for this option should be removed. I.e. if the user adds their own acorn plugin to parse this, everything should still work. This will reduce some complexity for us.\r\n- [ ] Add an option `inlineDynamicImports` to control if dynamic imports are inlined.\r\n  - This option will only be observed if a single entry point is provided; for multiple entry points, setting it to `true` will throw an error (or a warning that the option is ignored)\r\n  - The default will be `false`. In case `file` is provided, the necessary `dir` will be the directory of the output file\r\n  - In case the option is not provided and we have IIFE or UMD as the output format and a dynamic import is used, an error should be thrown\r\n\r\n### `experimentalCodeSplitting`\r\n- [ ] This option should be removed and be made active by default\r\n- [ ] Internally, there is still quite a bit of duplication between the code-splitting and non-code-splitting workflows, especially in `src/rollup/index.ts` but also in `Graph.ts`. This is problematic as improvements being made for one workflow will not automatically propagate to the other. With the recent improvements for code-splitting, it should be possible to map the non-code-splitting case to the code-splitting case and get rid of the code path of the former. If there are performance concerns, we should make sure that any additional logic in the code-splitting case executes as quickly as possible in situations where it is not necessary.\r\n- [ ] If input is an array of length 1 or a single entry should be treated the same way. This is important for the CLI where it is not easily possible to specify an array of length 1. Instead\r\n- [ ] The question where output files are generated and how they are named should be primarily decided by the presence of the `dir` option:\r\n  - [ ] If `dir` is present, adding the `file` option should produce at least a warning.\r\n  - [ ] If `dir` is present, using `iife` or `umd` formats should produce an error.\r\n  - [ ] If `dir` is present, output file names will respect the `chunkNames`/`entryNames` options\r\n  - [ ] If `dir` is missing, providing more than one input should produce an error\r\n  - [ ] If `dir` is missing, providing an alias name for a single input either via CLI or `input` option should produce at least a warning\r\n  - [ ] If `dir` is missing, providing the `manualChunks` option should produce an error\r\n  - [ ] All plugin hooks should be reviewed for compatibility and if we need interface changes\r\n    - [ ] `transformBundle`\r\n   - [ ] new `transformChunk` hook? #2043\r\n    - [ ] other hooks?\r\n\r\nThere may be more ideas to add to this list/things to be discussed/things that were missed. Looking forward for feedback. Might make sense to add `experimentalPreserveModules` here as well."},"comment":{"url":"https://api.github.com/repos/rollup/rollup/issues/comments/388614513","html_url":"https://github.com/rollup/rollup/issues/2092#issuecomment-388614513","issue_url":"https://api.github.com/repos/rollup/rollup/issues/2092","id":388614513,"user":{"login":"lukastaegert","id":12949268,"avatar_url":"https://avatars2.githubusercontent.com/u/12949268?v=4","gravatar_id":"","url":"https://api.github.com/users/lukastaegert","html_url":"https://github.com/lukastaegert","followers_url":"https://api.github.com/users/lukastaegert/followers","following_url":"https://api.github.com/users/lukastaegert/following{/other_user}","gists_url":"https://api.github.com/users/lukastaegert/gists{/gist_id}","starred_url":"https://api.github.com/users/lukastaegert/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/lukastaegert/subscriptions","organizations_url":"https://api.github.com/users/lukastaegert/orgs","repos_url":"https://api.github.com/users/lukastaegert/repos","events_url":"https://api.github.com/users/lukastaegert/events{/privacy}","received_events_url":"https://api.github.com/users/lukastaegert/received_events","type":"User","site_admin":false},"created_at":"2018-05-13T09:51:40Z","updated_at":"2018-05-13T09:51:40Z","author_association":"CONTRIBUTOR","body":"> Perhaps we should make the code splitting distinction that input is for a single entrypoint, and that entryPoints can be a new option for code splitting rather\r\n\r\nI guess you are right, rollup IS getting confusing. There seems to be some interest in such a feature.\r\n\r\nI think the idea that people have is that having input as an array will just build independent bundles using the same options and some sensible naming logic and place the results in `dir`. And it DOES make sense and is closer to the use cases of library developers who are still some of our most important users.\r\n\r\nMaybe at the same time we get rid of the array form for code-splitting as the object form is superior in most ways?"}}
{"actor":{"display_login":"lukastaegert"}}