├── README.md ├── 2016-09 ├── september-21.md └── september-07.md ├── 2016-06 ├── june-24.md └── june-29.md ├── 2016-08 ├── august-31.md ├── august-24.md └── august-05.md └── 2016-07 ├── july-29.md ├── july-22.md ├── july-08.md └── july-15.md /README.md: -------------------------------------------------------------------------------- 1 | # Webpack Core Meeting Notes 2 | 3 | The Webpack Core team meets once a week to discuss the development of Webpack, future plans, and priorities. 4 | These notes are very new and started June, 2016. 5 | 6 | New notes will be added as pull requests so you will be notified of them if you watch the repo. 7 | You can comment on the pull requests to discuss the notes, or raise issues if you would like to ask for a clarification. 8 | 9 | The repo format is inspired by [React Core Notes](https://github.com/reactjs/core-notes) which was inspired by [Ember Core Notes](https://github.com/emberjs/core-notes). 10 | 11 | ## Recent Notes 12 | 13 | ###2016 14 | 15 | #### June 16 | 17 | * [June 24th](2016-06/june-24.md) 18 | * [June 29th](2016-06/june-29.md) 19 | 20 | #### July 21 | 22 | * [July 8th](2016-07/july-08.md) 23 | * [July 15th](2016-07/july-15.md) 24 | * [July 22nd](2016-07/july-22.md) 25 | * [July 29th](2016-07/july-29.md) 26 | 27 | #### August 28 | 29 | * [August 5th](2016-08/august-05.md) 30 | * [August 24th](2016-08/august-24.md) 31 | * [August 31st](2016-08/august-31.md) 32 | 33 | #### September 34 | 35 | * [September 7th](2016-09/september-07.md) 36 | * [September 21st](2016-09/september-21.md) -------------------------------------------------------------------------------- /2016-09/september-21.md: -------------------------------------------------------------------------------- 1 | ## September 21 ([discuss](https://github.com/webpack/meeting-notes/pull/14)) 2 | 3 | ### Attendees 4 | 5 | * [Tobias Koppers](http://github.com/sokra) 6 | * [Sean Larkin](http://github.com/thelarkinn) 7 | * [Juho Vepsäläinen](http://github.com/bebraw) 8 | 9 | 10 | ### Agenda 11 | 12 | #### Documentation Updates 13 | 14 | * Juho is going to start working on [antwar/antwar#103](https://github.com/antwarjs/antwar/issues/103) next week. 15 | 16 | * Big styling [PR merged](https://github.com/webpack/webpack.js.org/pull/174). Styling is looking very good, with more responsive changes coming later. 17 | 18 | * Mobile support? 19 | 20 | * Being tracked via [#183](https://github.com/webpack/webpack.js.org/issues/183) 21 | 22 | * Add changelog section for docs page: 23 | 24 | * Link to [releases page](https://github.com/webpack/webpack/releases) 25 | 26 | * Should clarify `concepts` vs `api` vs `configuration` sections what they mean, etc. 27 | 28 | * At 45% completion now. Will still want to post a publication (when we have time that has a clear call to action explaining exactly what remains for webpack 2 docs to be satisfied). 29 | 30 | #### Analytics 31 | 32 | * Sean whipped up a proof of concept plugin: [AnalyticsWebpackPlugin](https://github.com/thelarkinn/AnalyticsWebpackPlugin) for us to use in the future in core. 33 | 34 | * When we get near to releasing, maybe we want to start collecting usage statistics in hopes to collecting useful data for target documentation, support, and more. Fine tuning from the community is always welcomed. The repo can be a proof of concept before we consider merging it to core. 35 | 36 | #### Project Boards 37 | 38 | * New [project boards](https://github.com/webpack/webpack/projects) (thanks github!). 39 | 40 | * Share the [help wanted board](https://github.com/webpack/webpack/projects/2)!! 41 | 42 | * Would love to find better ways to manage the board as issues tied to them get managed, maybe something we will have to wait for the community to catch up with. 43 | 44 | 45 | ### Takeaways 46 | * Documentation 47 | 48 | ----------- 49 | Please feel free to discuss these notes in the [corresponding pull request](https://github.com/webpack/meeting-notes/pull/14). 50 | -------------------------------------------------------------------------------- /2016-06/june-24.md: -------------------------------------------------------------------------------- 1 | ## June 24 ([discuss](https://github.com/webpack/meeting-notes/issues/1)) 2 | 3 | ### Attendees 4 | 5 | * [Tobias Koppers](http://github.com/sokra) 6 | * [Johannes Ewald](http://github.com/jhnns) 7 | * [Sean Larkin](http://github.com/thelarkinn) 8 | * [Juho Vepsäläinen](http://github.com/bebraw) 9 | 10 | ### Agenda 11 | 12 | #### Discussed Roadmap 13 | 14 | * Most important feature is documentation for Webpack 2.0. 15 | * There is a lot of great overlap with SurviveJs Book and Juho mentioned his willingness to take the lead on documentation. 16 | * Agreed that the Roadmap documentation should reflect bugs which have been fixed, as well as bugs that still are critical blocking for 2.0 17 | 18 | #### 2.0 Documentation. 19 | 20 | * New Repo (and new page? webpack.io? (looks like domain grabber owns it)) 21 | * Sean mentioned that the angular team uses a 3rd party for angular.io, and potentially we could investigate the same thing. (Maybe even a team willing to put out their brand on our page if they did it or a portion or all for free). 22 | 23 | #### Tobias added a new AgressiveSplittingPlugin for webpack 2.0 24 | 25 | * Support HTTP2 caching level 4 26 | 27 | #### Bounty Sourcing / Sponsorship 28 | 29 | * Sean mentioned that he is in communication with parties who are investigating the possibility of sponsorship or ‘helping’ in some way. He will find out more information on this today for next meeting. 30 | 31 | #### Weekly Meetings 32 | 33 | * Everyone agreed that meeting weekly to continue transparency. 34 | * Meeting notes will be published to webpack/meeting notes. 35 | * Next meeting slated for Jun. 29th 2016 36 | 37 | ### Takeaways 38 | * Look into finding a team for documentation (Juho) 39 | * Continue looking for Support/Sponsors for Webpack (Sean) 40 | * Update Roadmap to reflect where we are (Sean) 41 | * Inform on Breaking Changes (Johannes) 42 | * Work on Standardized Ts loaders/plugins (Sean) 43 | * WP 2.0 Typings (Sean) 44 | * Keep Close Communication with Loader and Plugin Authors (Johannes/Sean) 45 | * Create Chat for communication on gitter? (Sean/Tobias) [Loader Authors](https://github.com/orgs/webpack/teams/loader-authors) 46 | * Get List of Webpack loaders and plugins that need maintainers (Tobias) 47 | * Talk about Issue Tracking for Github Webpack Next Week. 48 | * Work with Webpack users to get a list of common questions. We’ll leave top 3 with answers in notes (Sean). 49 | 50 | ----------- 51 | Please feel free to discuss these notes in the [corresponding issue](https://github.com/webpack/meeting-notes/issues/1). -------------------------------------------------------------------------------- /2016-08/august-31.md: -------------------------------------------------------------------------------- 1 | ## August 31 ([discuss](https://github.com/webpack/meeting-notes/pull/12)) 2 | 3 | ### Attendees 4 | 5 | * [Tobias Koppers](http://github.com/sokra) 6 | * [Sean Larkin](http://github.com/thelarkinn) 7 | * [Johannes Ewald](http://github.com/jhnns) 8 | * [Juho Vepsäläinen](http://github.com/bebraw) 9 | 10 | 11 | ### Agenda 12 | 13 | #### Documentation Updates 14 | * Multiple PR's have been merged, including [#77](https://github.com/webpack/webpack.io/pull/77) by [@pksjce](https://github.com/pksjce) which increased our [milestone](https://github.com/webpack/webpack.io/milestone/1) completion to 30%!! 15 | 16 | * Sean inquired we should create additional incentive for users to help write documentation. The following ideas were considered: 17 | 18 | * Add contributors recognition on created pages (that they have 'touched'). 19 | 20 | * Some sort of T-shirt, swag, etc. 21 | 22 | * Sean mentioned he was working on the finishing touches to [#81](https://github.com/webpack/webpack.io/pull/81). This will help shape a "First-time user journey." 23 | 24 | * Some features are still missing from the docs page that we should have before release: 25 | 26 | * Ability to sort articles (for sidebar and flow). [#93](https://github.com/webpack/webpack.io/issues/93) 27 | 28 | * Ability to tie relavant articles (like wikipedia's md). [#94](https://github.com/webpack/webpack.io/issues/94) 29 | 30 | * Per-doc contrib generation [#95](https://github.com/webpack/webpack.io/issues/95) 31 | 32 | #### Scope Collapsing/Module Inlining 33 | 34 | * Tobias spent a bit of time working on a tool that will both assist in scope collapsing/module inlining as well as serve for Analyzing scope, high-level compression and minification. We haven't released it yet but could be coming soon in a separate public repo. Like we mentioned in last meeting, it would be good to have multiple members of the community help us approach this tool as an all around solution. Once we finish tackling webpack 2 defects and documentation, we can revisit this. 35 | 36 | #### Logo 37 | 38 | * With new docs and design around the corner Johannes wanted to know if we could revisit the design of the logo, and iterate over some ideas. All were for this. 39 | 40 | * We will hold off on looking into t-shirts until the logo has been overhauled. 41 | 42 | #### Domain 43 | 44 | * We discussed between `webpack.js.org` and `webpack.github.io` briefly, but it was tabled for next week. The continuing discussion on this is due to the implications that a domain change may have on traffic. 45 | 46 | ### Takeaways 47 | * Documentation! 48 | * Create github issues for new docs features (Sean). 49 | * Research webpack.js.org and webpack.github.io for webpage. 50 | 51 | ----------- 52 | Please feel free to discuss these notes in the [corresponding pull request](https://github.com/webpack/meeting-notes/pull/12). 53 | -------------------------------------------------------------------------------- /2016-07/july-29.md: -------------------------------------------------------------------------------- 1 | ## July 29 ([discuss](https://github.com/webpack/meeting-notes/pull/7)) 2 | 3 | ### Attendees 4 | 5 | * [Tobias Koppers](https://github.com/sokra) 6 | * [Sean Larkin](http://github.com/thelarkinn) 7 | * [Juho Vepsäläinen](http://github.com/bebraw) 8 | * [Johannes Ewald](http://github.com/jhnns) 9 | * [Jesus Rodriguez](https://github.com/foxandxss) 10 | * [Spencer Stark](https://github.com/spencerstark) 11 | 12 | 13 | ### Agenda 14 | 15 | #### Documentation Updates 16 | 17 | * Juho working on documentation, which is going well. His time was stretched a little thin this week and he didn't get as far as he wanted to. 18 | 19 | * Jesus hasn't been as available as he would like, but is working on documentation as his time permits. 20 | 21 | * Want to know the progress on the documentation? 22 | 23 | * Progress on documentation can be found in the [Readme](https://github.com/webpack/webpack.io#content-progress) 24 | 25 | * We are in the process of discussing Domain names and have set a milestone for next weeks meeting, more on this in takeaways. 26 | 27 | #### Configuration 28 | 29 | * With regards to [Usability Discussion](https://github.com/webpack/webpack/issues/2797) 30 | 31 | * Johannes spoke to the difficulty of setting up a configuration file. 32 | 33 | * If people are having a hard time understanding and setting up the configuration, we need to cater to the set up process and provide information and tools to help them get set up and going easier. 34 | 35 | * Strive for simplicity. 36 | 37 | * With Webpack 2 we hope to simplify configuration. A config can be as simple as entry and output. 38 | 39 | * There are different approaches we can take to simplify the configuration for people new to Webpack. 40 | 41 | * Validation 42 | 43 | * We could come up with a validation system to make sure that the webpack.config is correct and valid. 44 | 45 | * IDE Support 46 | 47 | * We would want to brain storm on this further. 48 | 49 | * What about a UI for configuration? 50 | 51 | * This could potentially help with those who haven’t used Webpack before to get going for the first time. 52 | 53 | * This could certainly make it easier for beginners. 54 | 55 | * There is certainly room to remove the complexity 56 | 57 | #### Overview of loader teams work 58 | 59 | * What are the thoughts about the loader teams? 60 | 61 | * We're extremely happy with how they’re coming along. 62 | 63 | * The way the HTML Loader was laid out was very notable. 64 | 65 | #### SystemJS 66 | 67 | * Guy Bedford has been kind enough to investigate [SystemJS (Registry) Target for Loader Spec](https://github.com/webpack/webpack/issues/2810) for Webpack. 68 | 69 | * Sean wants to spend time and use the plugin to understand it better and will follow up with implementation details. 70 | 71 | ###Takeaways 72 | 73 | * Sean 74 | 75 | * Start list for possible domain names for discussion next meeting. 76 | 77 | * Communicate and promote the documentation process. 78 | 79 | * Johannes 80 | 81 | * Create a list of configuration options we can simplify for discussion next meeting. 82 | 83 | ----------- 84 | Please feel free to discuss these notes in the [corresponding issue](https://github.com/webpack/meeting-notes/pull/7). 85 | -------------------------------------------------------------------------------- /2016-07/july-22.md: -------------------------------------------------------------------------------- 1 | ## July 22 ([discuss](https://github.com/webpack/meeting-notes/pull/6)) 2 | 3 | ### Attendees 4 | 5 | * [Tobias Koppers](https://github.com/sokra) 6 | * [Sean Larkin](http://github.com/thelarkinn) 7 | * [Juho Vepsäläinen](http://github.com/bebraw) 8 | * [Spencer Stark](https://github.com/spencerstark) 9 | * [Guy Bedford](https://github.com/guybedford) 10 | 11 | #### Attendee Notes: 12 | Guy Bedford was kind enough to join us to help tackle integration of Webpack w/ the Loader Spec and/or SystemJS. 13 | Spencer was in attendance to take meeting notes. 14 | 15 | ### Agenda 16 | 17 | #### Documentation Updates 18 | * Juho is currently working on documentation, all is going well. He's getting ready to submit a pull request with his current works with the intent to merge soon. After this grooming and reviewing issues will take place. 19 | * There will be another blog post with regards to documentation and the process coming soon. 20 | 21 | #### Core Loaders and Plugins 22 | * We all agreed on the following list of repository team leads: 23 | * JSON5-loader: **gdi2290** 24 | * HTML-loader: **hemanth** 25 | * Mocha-loader: **tricoder42** 26 | * Transform-loader: **minwe** 27 | * JShint-loader: **kostasmanionis** 28 | * I18n-webpack-plugin: **ecutdavid** 29 | * Grunt-webpack **danez** 30 | * Karma-webpack: **mikaak** 31 | * Component-webpack-plugin (deprecated) 32 | * Tobias thinks we should consider deprecating and leaving this plugin alone. 33 | * Compression-webpack-plugin 34 | * Team lead => (?) 35 | 36 | #### Initial tasks for teams 37 | 38 | * Mimic issue templates / types from webpack/webpack 39 | * This will be some of the first “Pilot PR’s” for these teams once created 40 | * Review old PRs in repos, start to implement support for webpack 2.0 breaking changes 41 | * Continue to monitor and support once established 42 | * Add testing 43 | 44 | #### SystemJS 45 | * SystemJS is pretty well documented and well flushed out and positioned well for integrations 46 | * Challenges: 47 | * Static loader, dynamic bundler? 48 | * a library that's usable in system js? 49 | * Private v. public modules 50 | * External modules with a systemJS call to load it. 51 | 52 | * Thoughts: 53 | * Would need to be a normal output file with a systemjs suffix on it? 54 | * If you have a `System.import` with some module name as an identifier, you’ll want to know which module to get with the dynamic loader 55 | * You need some sort of mapper to a public registry? (From chunk ID's to names) 56 | * Guy suggested the concept of public modules, public module loader vs webpack. 57 | * Tobias mentioned that this has been done already before for another plugin (`DllPlugin`) and that we could resuse a lot of the functionality 58 | * Most modules need to be loaded, but not all. 59 | * You’re plucking some modules out and exposing them (to the registry) and these ones would then be webpacked?. 60 | 61 | * Would this be a plugin? 62 | * Might be better as a library? 63 | * Yes, it would be, and potentially expose the entry points and the needed 'public modules'. 64 | * Would be a libraryTarget setting. IE: `libraryTarget: 'systemjs'` 65 | * Probably an underlying plugin will be written 66 | 67 | ###Takeaways 68 | 69 | * Send out official invites for core team (Tobias) 70 | * Create issue for Guy/Tobias to work on for SystemJs/Webpack integration (Sean) 71 | * Continue documentation effort. Clean up github issues with labels and more organization (Juho) 72 | 73 | ----------- 74 | Please feel free to discuss these notes in the [corresponding issue](https://github.com/webpack/meeting-notes/pull/6). 75 | -------------------------------------------------------------------------------- /2016-07/july-08.md: -------------------------------------------------------------------------------- 1 | ## July 8 ([discuss](https://github.com/webpack/meeting-notes/pull/4)) 2 | 3 | ### Attendees 4 | 5 | * [Johannes Ewald](http://github.com/jhnns) 6 | * [Sean Larkin](http://github.com/thelarkinn) 7 | * [Juho Vepsäläinen](http://github.com/bebraw) 8 | * [Jesus Rodriguez](https://github.com/foxandxss) 9 | * [Spencer Stark](https://github.com/spencerstark) 10 | 11 | #### Attendees Notes 12 | 13 | * Jesus and Spencer joined us today for the Google hangout. Jesus is working directly with Juho for documentation on webpack/webpack.io and his involvement was pertinent. Spencer is helping Sean take documentation and meeting notes. 14 | 15 | ### Agenda 16 | 17 | #### Medium and Publications 18 | 19 | * [The initial post about webpack on medium](https://medium.com/webpack/webpack-its-getting-real-92c60fca1db1#.8nv2qek91) was really well received. Juho said that week’s meetings notes should accompany a publication. Everyone was in agreement. We will add it to the checklist of things we'll make sure is included when we post our weekly publication. Sean suggested to continue to publications on Saturday Morning (CST) and everyone was happy with this. 20 | 21 | * The next article will be on documentation, which is in review now. It will contain a call to action for involvement in the webpack/webpack.io documentation process. We will also want to thank [people for offering their time maintaining Plugins and Loaders](https://github.com/webpack/webpack/issues/2734) which has already had some great feedback. 22 | 23 | #### Documentation 24 | 25 | * Antwar open source library for documentation. Tobias mentioned previously that we will have a separate page in documentation that will support dynamic content (JavaScript). We will have to wait and see what ideas he is cooking up for documentation tools/utils. 26 | 27 | #### Slack 28 | 29 | * Sean mentioned starting a webpack slack org. We tossed the idea around about tying out slack and decided we will pilot the slack org that Sean has. If it is successful, we could potentially open this up to people to generate invites to (like slackr) and join. 30 | 31 | #### Core Loaders and Plugins 32 | 33 | * There was awesome response from people. Sean suggested we have two to three people per repository. We will have to sort through the list of pledges and assign to the best of our ability those who are interested (after being vetted). 34 | 35 | * We discussed privileges and pull requests in regards to these loaders and we thought best to wait until teams are solidified before creating a standard. 36 | 37 | * The first work that we will call on maintainers will be to mimic issue templates / types from webpack/webpack (where relevant) so that issues are high quality across the board. We have seen a huge influx in HIGH QUALITY github issues, and they are triaged and fixed easier because of this. 38 | 39 | * This will be some of the first “Pilot Pull Requests” for these teams once created. 40 | 41 | * They will also need to review old pull requests in repositories, start to implement support for webpack 2.0 breaking changes. 42 | 43 | * Continue to monitor and support once established. 44 | 45 | #### Sponsorship 46 | * Still looking at options 47 | 48 | * Needing to find a list of organizations that utilize webpack as a core tool (IE. Trivago, Webflow, etc.) 49 | 50 | 51 | 52 | ### Takeaways 53 | * Sort and vet people for core loaders and plugins (Sean/Johannes) 54 | * Clean up Pull Requests (all) 55 | * Review Medium Article (all) 56 | * Domain follow up for _[webpack.io]_ (Sean) 57 | * Twitter handle follow up _[@webpack]_ (Sean) 58 | * Pilot test Slack for webpack, see if it helps the core team collaborate easier. (Sean/Juho) 59 | 60 | 61 | 62 | ----------- 63 | Please feel free to discuss these notes in the [corresponding pull request](https://github.com/webpack/meeting-notes/pull/4). 64 | -------------------------------------------------------------------------------- /2016-08/august-24.md: -------------------------------------------------------------------------------- 1 | ## August 24 ([discuss](https://github.com/webpack/meeting-notes/pull/11)) 2 | 3 | ### Attendees 4 | 5 | * [Sean Larkin](http://github.com/thelarkinn) 6 | * [Tobias Koppers](http://github.com/sokra) 7 | 8 | 9 | #### Attendee Notes: 10 | Johannes is in Iceland at JSConf Iceland (Good luck!), and Juho was unable to make the meeting today. 11 | 12 | ### Agenda 13 | 14 | #### Documentation Updates 15 | 16 | * We were able to reach [Marco Pai](https://github.com/MarcoPai), however the offer he kindly extended to us for puchase of webpack.io was too steep. We may consider keeping the existing domain, as the traffic is extremely high. We decided to talk about this after documentation has been a little bit more fleshed out. 17 | 18 | * We have had some more pull requests for documentation, however on the current pace we are at, it is most unlikely that we will not be able to release the beta tag from webpack 2 just yet because we have not fullfilled our [milestone/plan of action](https://github.com/webpack/webpack.io/issues?q=is%3Aopen+is%3Aissue+milestone%3A%22Webpack+2+-+Documentation+MVP%22). We are working on getting the site deployed, so that it is easier for people to see and use the new documentation page. Contributions should be as easy as getting a github link for the document you are looking at and then commiting the changes, and submitting a PR. 19 | 20 | #### Reported Issues 21 | 22 | **Tree Shaking / Optimization** 23 | * We discussed briefly our disappointment that [UglifyJS2](https://github.com/mishoo/UglifyJS2/issues/1261) is not willing to work on a solution to to remove side-affects from transpiled unused ES6 exported classes transpiled to ES5 (by both Typescript and Babel). [#2867](https://github.com/webpack/webpack/issues/2867). 24 | 25 | * We decided that this is not a responsibility of *webpack*, however we see the need for a very strong general purpose tool that needs to be developed. Tobias suggested that we (along with the community) build a tool that handles the following: 26 | 27 | * Anyone could use it, and we would leverage it in a plugin like UglifyJSPlugin 28 | * Complex side effect analysis to figure out it if the exported declaration is sideeffect-free, and not used somewhere else. 29 | * Reading the AST, create a dependency graph of variables and references, Have some common templates for optimization, figure out what is unused, write the new AST. 30 | * Cover all the edge cases: `eval`, `with`, global scope, `arguments`, conditionals 31 | * Program, Flow Analysis 32 | * It would be a general purpose optimization not specific to webpack. 33 | 34 | * After we integrate Rollup features into webpack and then potentially usability changes (post 2.x release). We hope this will be a tool collaboratively developed in parallel by many interested parties (including ourselves) in this endeavor as it mutually benefits the entire javascript community. 35 | 36 | **Rollup / Module Inlining** 37 | * Because of the UglifyJS2 issue and results, It was appropriate to bring up the next steps in development after 2.x which is adding the module inlining, and what incremental steps we can take in development to start working on this. Webpack currently does not have plugin hooks for combining modules (a key feature of Rollup/Module Inlining). Tobias said this would be one of the first easier steps to make towards this feature. It could also allow people to work on implementations themselves if they wanted to. Second step will be using the same "variable deconflictor" that rollup uses to help make conflicts in variable names trivial. 38 | 39 | ###Takeaways 40 | * **Documentation:** We need our milestone completed. Completing this goal is crucial for the community. 41 | 42 | ----------- 43 | Please feel free to discuss these notes in the [corresponding pull request](https://github.com/webpack/meeting-notes/pull/11). 44 | -------------------------------------------------------------------------------- /2016-07/july-15.md: -------------------------------------------------------------------------------- 1 | ## July 15 ([discuss](https://github.com/webpack/meeting-notes/pull/5)) 2 | 3 | ### Attendees 4 | 5 | * [Johannes Ewald](http://github.com/jhnns) 6 | * [Sean Larkin](http://github.com/thelarkinn) 7 | * [Juho Vepsäläinen](http://github.com/bebraw) 8 | * [Jesus Rodriguez](https://github.com/foxandxss) 9 | * [Tobias Koppers](https://github.com/sokra) 10 | 11 | #### Attendees Notes 12 | 13 | * Jesus joined us today for the Google hangout. Jesus is working directly with Juho for documentation on webpack/webpack.io and his involvement is pertinent. 14 | 15 | ### Agenda 16 | 17 | #### Medium and Publications 18 | 19 | * We are have great response from our Medium publications still but we are tweaking the time and dates that we want to release. Juho said that we can try monday instead of saturday morning (CST) to release the publication. Johannes suggested Friday daytime, however we decided in the end to publish this Monday, and then continue to play with the date/time. 20 | 21 | * Tobias offered to write this weeks publication article which will be an informative look into the AgressiveSplitPlugin. This will go out on Monday and will need to be reviewed by the team. 22 | 23 | #### Typescript Typings 24 | 25 | * Sean brought up that there has been multiple responses from individuals to not only bring typings to webpack 2.x, but also include official typings into the repository. Sean mentioned that the benefits could allow people to use typescript in their configurations and have automatic type validation. Tobias asked if we would have these tested incase changes are made. Sean said that we could write tests that allow the types to test against the webpack compiler and configuration and plugin api & that it would be a huge benefit for users and developers on core. A typings file would simply be added to the repository and a `'typings'` field added to the package.json. Everyone agreed to this as long as it is tested and integrated into the CI process. Sean mentioned he has one or two people already offering to assist him with this and will now look into this even further. 26 | 27 | #### Documentation 28 | 29 | * Stubs for learning resources continue to pour into the github. 30 | 31 | * Sean has offered to take on some of the Plugin API documentation when he gets around to it after his angular-cli webpack integration work. Also asked if Tobias would be willing to write the high level overview documentation for the Resolver instance. It is currently the least documented Plugin API feature and it would be great to have Tobias write it so that no stones are unturned about its use. 32 | 33 | * The `antwar` [branch](https://github.com/webpack/webpack.io/tree/antwar) which contains most of Juho's work is nearing its point of completion. Juho states that a PR will be coming within the next week or so with all the content changes. 34 | 35 | #### Slack 36 | 37 | * Sean recapped that he finally set up and sent out slack to the core team members. The team decided that we would try it out, as well as invite plugin and loader authors in hopes of specifically communicating with them more efficently. 38 | 39 | #### Core Loaders and Plugins 40 | 41 | * Juho has created a document with initial sorting and assignment for loaders and plugins. Sean mentioned that he will go through this list and add anyone else that remains. Once this list is approved we will send to Tobias to extend invitations to the organization and repos. 42 | 43 | #### CSS Loader & CSS Modules 44 | 45 | * Johannes brought up that there are still a number of performance related issues in regards to `css-loader` and inquired whether or not it would be possible to isolate the css-modules code from the loader. Tobias said that the changes he had made which were thought to increase performance were not as good as promised. Johannes asked if we could instead have two separate loaders so that people who do not want to use css-modules can simply use a faster lightweight css-loader option instead. Tobias said it may be possible and would look into it. 46 | 47 | ### Takeaways 48 | * Finalize vetting people for core loaders and plugins (Sean) 49 | * Clean up Pull Requests (all) 50 | * Review Medium Article (all) 51 | * Finish article for publication on HTTP2 & Webpack. 52 | * Look into separate loader for CSS vs CSS-Modules (Tobias/Johannes) 53 | * Start gathering a full team to work on webpack typings. 54 | 55 | 56 | ----------- 57 | Please feel free to discuss these notes in the [corresponding pull request](https://github.com/webpack/meeting-notes/pull/5). 58 | -------------------------------------------------------------------------------- /2016-06/june-29.md: -------------------------------------------------------------------------------- 1 | ## June 29 ([discuss](https://github.com/webpack/meeting-notes/pull/2)) 2 | 3 | ### Attendees 4 | 5 | * [Tobias Koppers](http://github.com/sokra) 6 | * [Johannes Ewald](http://github.com/jhnns) 7 | * [Sean Larkin](http://github.com/thelarkinn) 8 | * [Juho Vepsäläinen](http://github.com/bebraw) 9 | 10 | ### Agenda 11 | 12 | #### Repo Management Tools 13 | 14 | * Discussed briefly using Github management tools to help: 15 | * Move issues between repos: 16 | * Apply Issues to multiple repos: 17 | * Track and coordinate milestones across repos: 18 | 19 | #### Documentation 20 | 21 | * Tobias worked on an [outline](https://github.com/webpack/webpack.io/commit/18b7f14d686b76775d1b5de763423d121bc28f0b) that could serve as a foundation for webpack/webpack.io. 22 | * Had one or two volunteers express interest in working on documentation however we will want to have a handful of folks working on documentation. (Because there is a lot to document). 23 | * Suggestions were made to create individual issues for each of the "topics or features" for webpack so that we can easily track our progress. 24 | * Sean is still looking for a company who specializes in content creation etc. to help donate their efforts if possible. 25 | * We will start to tag issues in github that we have answered/found useful for people with the `documentation` tag so that we can address them in the future documentation 26 | 27 | #### Releasing Webpack 2.x Official 28 | 29 | * Sean has created a filter of [current reported issues](https://github.com/webpack/webpack/issues?q=is%3Aopen+is%3Aissue+label%3Abug+label%3Awebpack-2+sort%3Acreated-asc+label%3A%22in+planning%22) that Tobias is going to look through to see if it has been already fixed, or if it is by design/not a bug, etc. 30 | * We agreed that a 2.x RC/Official Release milestone will be created that will assist us in tracking what remains. This will propose somewhat of a challenge because there is webpack/webpack-dev-server and other repo's to ensure are up to date to any breaking changes. 31 | * Also working on PR Issues, support for problems from @gaearon and @gdi2290 (Strong representatives from the Angular and React communities). 32 | * In the end Documentation for [webpack/webpack.io](http://github.com/webpack/webpack.io) will be the **critical blocker**. Otherwise, only easy/small features/bugs remain. 33 | * Backporting the --env `function` style webpack config definition so that transition is easier for users can use the feature if desired going from webpack 1.x to webpack 2.x. 34 | 35 | #### Releasing After Webpack 2.x Official 36 | 37 | * Adding an InlinePlugin (name TBD) that will support RollUp style inlining of modules for ES6 tree shaking capabilities. But requires core changes and should happen after 2.x release. 38 | * 39 | 40 | #### Public awareness 41 | 42 | * In addition to adding the meeting-notes as public Tobias brought up the idea of a Medium publication that all of the core team members can post on. The 'voice' of webpack tailored by the community's needs and wants. The Content will contain: 43 | * Looking for maintainers for some repos 44 | * Webpack 2 release plan 45 | * Documentation plan 46 | * Slack 47 | * Sponsor/Donations plan 48 | * Team members 49 | * Thanks to loader authors 50 | * Ask what people expect from a webpack blog 51 | * We want people to know that webpack 2.x not only represents a change in the code, but also dev community involvement, transparency, and support. #Webpack <3 #Developers 52 | 53 | ### Takeaways 54 | 55 | * Backport --env 56 | * Create a medium publication (tobias/sean) 57 | * Create a blog post (tobias/sean) 58 | * Find some more people to invite to maintain the loaders and plugins or decide to deprecate unused ones: (all) 59 | * karma-webpack 60 | * coffee-loader 61 | * component-webpack-plugin 62 | * grunt-webpack 63 | * mocha-loader 64 | * html-loader 65 | * compression-webpack-plugin 66 | * i18n-webpack-plugin 67 | * transform-loader 68 | * jshint-loader 69 | * json5-loader 70 | * coffee-redux-loader 71 | * coverjs-loader 72 | * Work on Standardized TypeScript loader/plugins if authors are willing CC @jbrantly & @s-panferov (Sean) 73 | * Create 2.0 Typings team to work with documentation team and changes to accurately be reflected in the typedefs (Sean) 74 | 75 | ### Common Questions 76 | 77 | 1. How does one do targeted webpack builds? 78 | Targeted webpack builds mean that you have multiple builds created for different devices, browser and support. Using tools like [parallel-webpack](http://tech.trivago.com/2015/12/15/parallel-webpack/) allows you to build multiple configurations in parallel. The example on [parallel-webpack](https://github.com/trivago/parallel-webpack#variants-example)'s github repository is a great example. 79 | 80 | 2. How does `LoaderOptionsPlugin` replace `UglifyJsPlugin` for minification. 81 | The `LoaderOptionsPlugin` delegates the minification and optimization to the loader itself. Therefore if the loader doesn't implement the properties (for 2.x) then nothing will happen. https://gist.github.com/sokra/27b24881210b56bbaff7#loader-options--minimize 82 | 83 | Please feel free to discuss these notes in the [corresponding pull request](https://github.com/webpack/meeting-notes/pull/2). 84 | -------------------------------------------------------------------------------- /2016-08/august-05.md: -------------------------------------------------------------------------------- 1 | ## August 5 ([discuss](https://github.com/webpack/meeting-notes/pull/8)) 2 | 3 | ### Attendees 4 | 5 | * [Sean Larkin](http://github.com/thelarkinn) 6 | * [Juho Vepsäläinen](http://github.com/bebraw) 7 | * [Johannes Ewald](http://github.com/jhnns) 8 | * [Jesus Rodriguez](https://github.com/foxandxss) 9 | 10 | #### Attendee Notes: 11 | Tobias is going to be on vacation for a couple weeks and thus wasn't present for this meeting. 12 | 13 | ### Agenda 14 | 15 | #### Documentation Updates 16 | 17 | * Sean has [merged](https://github.com/webpack/webpack.io/pull/59) our first [new documentation](https://github.com/webpack/webpack.io/blob/develop/content/concepts/index.md) into webpack/webpack.io!!!! Share it around, and provide feedback. It is still in a beta state as there is some link cleanups. But he wanted to provide a great introduction to people who haven't already had one. 18 | 19 | * We are still on the hunt for the `webpack.io` domain name. We see its registered to a gentleman in China, and would love any Mandarin speakers to help us draft an email to reach out to him for domain purchase as the first few emails have been unsuccessful!! [Marco Pai](https://github.com/MarcoPai) has some slight activity on github. So we aren't giving up hope just yet. 20 | 21 | * Currently the `webpack/webpack.io` is a statically generated site, so Juho is going to be working to add React and JS for Dynamic usage in other portions of the page. 22 | 23 | * Documentation Structure has been finalized!!!! Priority number one is now creating the content and merging it into develop! The styling for the page is still a work in progress, however that is our last priority before we "ship the docs". 24 | 25 | * For future we may have Johannes with the help of other UI Designers to create personas that help us and contributors create appropriate language for documentation. Agreed that it was a very-nice-to-have but also a great addition if we ever had time. 26 | 27 | * Would love to have folks work on a SchemaStore schema for the webpack configuration. This we could use to autogenerate some documentation like the API: Configuration page. Also could provide IDE support for people almost out of the box. Need to look into how to do this when we tackle that documentation. 28 | 29 | * It was brought up that we need to create a feasible action plan that we can share with the Dan Abramov's, Kent Dodds', and Patrick Stapleton's of the JS community to pass along and promote. It is in everyones best interest to work together to create documentation and having a strategy to accomplish this is vital. We spent time listing out the immediate MVP documents that would the team agreed could allow us to life the webpack 2.x beta status. 30 | 31 | * Juho created a [Github Milestone for all these tasks that we can give to people](https://github.com/webpack/webpack.io/issues?q=is%3Aopen+is%3Aissue+milestone%3A%22Webpack+2+-+Documentation+MVP%22)!!!! Barring any major or breaking changes from popular community loaders or plugins (as well as the core loaders and plugins), once this is finished, we believe this is our 'go-ahead' to lift the beta status. We all agreed that although this wouldn't contain all of the documentation we aspired to tackle, that this would give the (first time) users _that need it the most_, the opportunity to have a _far more_ augmented learning experience than what is available. 32 | 33 | * Everyone also agreed that we could technically accomplish this by the end of August. **Yes people, it's getting more than real, this is an estimated timeline of webpack 2.x being out of beta!** :heart_eyes: :heart_eyes: :heart_eyes:. If all goes well and we meet our deadline, then we can lay out our next milestone for more advanced "revisions" of our existing documentation migrated over to the `webpack/webpack.io` repo. 34 | 35 | * **We will want/need lots of help!!!** So please share the link of the milestone above. The milestone will also include general guidelines for how to author one of these docs. And once we have a collection of people we can meet weekly via hangout, etc. to track and manage the Milestone goals, etc. There is also a [getting started page](https://github.com/webpack/webpack.io/blob/develop/content/get-started.md) we have referenced on the repo as well for those worried about contributing. It doesn't have to be perfect the first time around. 36 | 37 | #### Publication 38 | 39 | * Sean admitted he has slacked a little bit on getting a new article for our publication, but wants to make it a priority to announce that the angular-cli and react-create-app are both powered by webpack now. 40 | 41 | * Its a huge milestone of integration for us. Including Laravel and Rails:Middleman and Grails new asset Pipline. The list of webpack users is seeming to continue to increase and the learning and constructive criticism continues to grow. This _is the tool you made and helped customize_ in the end, so every person, framework, library, boilerplate, MVC, that uses webpack is another win for you and the webpack team. 42 | 43 | #### Sourcemaps 44 | 45 | * We have had a bunch of reports of [sourcemap issues](https://github.com/webpack/webpack/issues/2145) brought to Sean's attention. He's going to attempt to continue and connect with the ChromeDevTools team to see what we can do here, or needs to be done to help fix this. 46 | 47 | ###Takeaways 48 | 49 | * Sean: 50 | 51 | * Obtain domain 52 | 53 | * Ping Marco Pai on github as well 54 | 55 | * Publication 56 | 57 | * Communicate Action Plan for Docs 58 | 59 | * Add Writers Guide on Readme.md for webpack.io. (https://github.com/webpack/webpack.io/blob/develop/content/writers-guide.md#article-structure) 60 | 61 | 62 | * Juho: 63 | 64 | * Add React Dynamic to AntwarJs. 65 | 66 | * The Community (You Reading This): 67 | 68 | * Spread the news about our [milestone/plan of action](https://github.com/webpack/webpack.io/issues?q=is%3Aopen+is%3Aissue+milestone%3A%22Webpack+2+-+Documentation+MVP%22) and help get the community together to bring a kick-ass learning experience for webpack users!!! Promote, share, contribute. Juho and Sean have promised to help revise and check any and all PR's that come in as a top priority if they will help close an issue on our Milestone. 69 | 70 | * We want you to tackle the issues listed in that link, and then join us in our [gitter doc chat](https://gitter.im/webpack/docs). This is where we will collaborate any efforts for documentation. Everyone is welcome!!! Thank you so much! 71 | 72 | ----------- 73 | Please feel free to discuss these notes in the [corresponding issue](https://github.com/webpack/meeting-notes/pull/8). 74 | -------------------------------------------------------------------------------- /2016-09/september-07.md: -------------------------------------------------------------------------------- 1 | ## September 7 ([discuss](https://github.com/webpack/meeting-notes/pull/13)) 2 | 3 | ### Attendees 4 | 5 | * [Tobias Koppers](http://github.com/sokra) 6 | * [Sean Larkin](http://github.com/thelarkinn) 7 | * [Johannes Ewald](http://github.com/jhnns) 8 | * [Juho Vepsäläinen](http://github.com/bebraw) 9 | 10 | 11 | ### Agenda 12 | 13 | #### Documentation Updates 14 | * Juho: Migrated a significant grouping of issues labeled `question` or `documentation` from [webpack/webpack](github.com/webpack/webpack) over to the [new docs page](github.com/webpack/webpack.js.org). 15 | 16 | * PR's are now in for adding helpful documentation linters and plugins 17 | * proselint: will help with grammar and has settings for rules etc. [#96](https://github.com/webpack/webpack.js.org/pull/96) 18 | 19 | * ESLINT module for codeblocks for markdown documents. This will ensure that our code examples are consistent across documents etc. [MERGED #97](https://github.com/webpack/webpack.js.org/pull/97) 20 | 21 | * Juho also suggested we look into `alex` which works with proselint on spelling and linting specific words based on topic (offensive, abbreviations, etc.) 22 | 23 | * Don't want linting too strict, just enough to provide, autoformatting, and eliminate the number of round of reviews for PR's. 24 | 25 | * The topic of Cont. Deployment came up for our documentation. We viewed some other pages and it apeard Codeship is a popular option as well as Travis but requires more work. An issue will be created in the docs repo. 26 | 27 | #### Publication Updates 28 | * Upon feedback, we discovered that Housing.com's engineering team had published an excellent article on medium about their success's with webpack. Sean suggested that we open up the option for authors who are interested, to post success stories and awesome information under our publication (after review). The team decided this would be fine since we have been slacking on our medium publication as of late. 29 | 30 | #### Domain 31 | * We discussed between `webpack.js.org` and `webpack.github.io`. After we did the research we decided that we would setup `webpack.js.org`. Tobias is going to tackle this a bit later today. 32 | 33 | #### Analytics 34 | * Sean asked whether or not we have page analyitcs on our docs site currently. Tobias gave access to all the analytic data. Sean also brought up the idea of having webpack the tool ask if users would let us submit analyitcs data. Tabeled discussion as its a severe nice-to-have. 35 | 36 | #### Logo 37 | * Johannes had prepared some simple mock ups for a new logo design. We discussed a few color options, and that we could poll the community however, we want to iterate on the design that we feel expresses our goals, etc. 38 | 39 | #### Issues/Defects 40 | * **[#1792](https://github.com/webpack/webpack/issues/1729)**: 41 | * This issue was brought up because it appears that our `node` target has been functioning this way for over a year with not one report until now. Tobias: "webpack should be identical to node in the `node` target". 42 | 43 | * By using `module` like this, webpack's runtime would take a significant hit. (`try-finally` bails out the V8 compiler [and its called for every `require()` call] ) 44 | * We will have to investigate the `node.js` repo and see if there is anyone coming across this issue already with useful knowledge. Otherwise we will create an edge-case target so that this can be used the proper way. We will discuss this more in detail next meeting. 45 | 46 | * **[#250](https://github.com/webpack/webpack/issues/250#issuecomment-199602293)**: 47 | * Johannes raised this issue because it is notable that some scaled builds take long to finish (even if it is 2-3 minutes). Johannes mentioned [`HappyPack`](https://github.com/amireh/happypack) is a common package that allows you to multithread the loader process. However there are struggles with the way that "hacky" loaders work that make `HappyPack` impossible for `awesome-typescript-loader` and `ts-loader` to implement together. 48 | * Sean describes this "hackyness" is when a loader accesses `compiler` properties from `this` such as `this._compiler` to execute plugin based functionality. Needs to be deprecated. 49 | * Tobias mentions that maybe we can add functionality to the loader API to allow this to work. Sean explained that the reason these TS loaders need plugin access is because it needs to defer typechecking until the `compilation` is finished. 50 | * Tobias mentions that deferred execution could be a feature we need to add to the loader API. Could also be useful for image sprites, etc. 51 | * Johannes brings up that this is the same problem to `extract-text-plugin` (when you need to apply a plugin and a loader together). 52 | * Tobias states that this could fix a great deal of "hackyness" from `extract-text-plugin` and move it to a loader. 53 | * Sean suggested that the deferred execution be expressed by unwrapping a promise. ( 54 | The loader function itself would return the promise. ) Would be minimal additional effort and easy for developers to understand. 55 | * Tobias mentioned that tool that would be moved and use the new deferred execution API [(doesn't exist yet but suggested idea) `image-sprite-loader` and the `seperate-css-loader`] would need to include an `invalidate` method to issue recompilation from the callback. It would also need to include the following: 56 | * errors/warnings 57 | * invalidating => recompilation w/ new data 58 | * emitting files 59 | * access to the current chunk info (edited) 60 | * additionally noted it would fall after optimization and before id creation (in the compilation step) 61 | * This would also allow ts-loader and awesome-typescript-loader to execute typechecking in the resolve promise. (allowing tools like HappyPack to execute loaders parallel/multithreaded) 62 | * Johannes mentions that it would be important that we get feedback from loader authors to see if this would help solve some of their issues (including HappyPack). 63 | * Tobias described, (once implementing this feature [based upon the comments in the linked issue]) that a `disk-cache-loader` would look similar to having the following. 64 | * pithing phase (this is a pitching loader) 65 | * check disk cache for an entry 66 | * if there is an entry: 67 | * hash all content of entry.dependencies 68 | * compare hash with entry 69 | * if equal: 70 | * return entry.source and entry.dependencies as result 71 | * continue loader execution 72 | normal phase: 73 | * store dependencies, hash of dependencies and source in disk cache (edited) 74 | * alternativly it could use loader-runner to run the remaining loaders. This would allow to cache more data: emitted files, errors, warnings. This would not be possible in the normal loader chain. 75 | * Issues will be created for each of these missing features. (Sean). 76 | * Additionally, with these changes we will plan on deprecating the following: 77 | * We are planing to deprecate all properties and methods that make a multi-thread compilation impossible, that is: 78 | * No synchronous APIs (resolveSync) 79 | * No shared state (_compiler) 80 | 81 | * We will provide deprecation warnings for version 2, that this will be deprecated in v3 82 | 83 | ### Takeaways 84 | * Documentation 85 | 86 | ----------- 87 | Please feel free to discuss these notes in the [corresponding pull request](https://github.com/webpack/meeting-notes/pull/13). 88 | --------------------------------------------------------------------------------