Upgrade webpack from 3.x to 4.6.0

[chriseppstein]

This project isn't a normal webpack integration. We need some folks who are great at webpack to help us upgrade and make sure our plugins are better integrated with the webpack ecosystem.

[samccone]

adding @TheLarkInn

[montogeek]

@chriseppstein What is missing to achieve this integration?

[TheLarkInn]

Probably the feature/css branch completion on webpack/webpack

…

On Wed, Apr 25, 2018, 7:29 AM Fernando Montoya ***@***.***> wrote: @chriseppstein <https://github.com/chriseppstein> What is missing to achieve this integration? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#128 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ADQBMBmEpCbt2WSRIV2HWwPOWl4a-jHbks5tsIhdgaJpZM4TinJE> .

[chriseppstein]

@montogeek I've tried two times now to upgrade and failed due to a lack of my own understanding and insufficient time to get up to speed on the numerous changes that have occurred in the last 9 months. I fully expect that most of the webpack integration code we have at this point is nothing more than a proof of concept showing how the css-blocks components tie together. The ways that we're integrating with webpack are not what I understand to be the golden path. In theory, CSS Blocks is doing things that webpack is supposed to enable and make easier: code-splitting, whole-app analysis and optimization, etc. But I've never been able to figure out how to leverage that infrastructure successfully.

I hope that now that we're open source, we can collaborate with people who understand it better and can help us get a rock-solid integration built.

[ForsakenHarmony]

I'd love to help out, but sadly don't know much about webpack loaders either

[alexparish]

I imagine this issue is preventing people from adopting CSS Blocks. Keen to help on this but just need some direction.

[chriseppstein]

@alexparish My current thinking has been to create a language server and try to make CSS blocks work primarily loader block files that communicates to the language server, with some hooks into the build/rebuild lifecycle to start/stop the server and to nuke its build cache appropriately. In this way, most of the logic can be kept in the language server and shared for different build tool integrations as well as Editor integrations with only minimal adaptor code for the different contexts.

From a webpack perspective, I think we need to change the approach for building so that we don't have to look at templates to discover block files. Instead, block files should be discovered by webpack's import/dependency architecture and intersected with templates later when deciding what css to produce.

All of this code needs to then use webpack 4's official CSS support which I don't understand at this time and so I don't really know how to use it correctly. This would supersede the janky CSS Asset support that I made to avoid the morass of pretending-CSS-is-JS-but-not-really-later-we-extract-it that was going on in 3.x.

So basically: It's a total rewrite of what we have right now. I'm open to suggestions and prototypes, etc.

[brandonkal]

Looking forward to Webpack 4/5 support so I can try this out with Gatsby and Preact projects. Parcel support would also be neat but Webpack is what is holding me back from using this project.

[DoctaCloak]

Hey out of curiosity what is the recent progress on this one? @chriseppstein

I'm learning a bit more about webpack this Fall/Winter and maybe I can help soon. But would my help be wanted or would you prefer someone from the webpack core team?

[chriseppstein]

@DoctaCloak I'm strictly focused on getting ember support released as 1.0 right now because that's what we use at LinkedIn. I will support and encourage contributors to help us get CSS Blocks working with JSX again but I won't have personal resources to contribute to that development during the next 6 months.