Feature: Enabling better extensibility & framework tooling integration

[addyosmani]

Working with @ev1stensberg @TheLarkInn & @developit on this one

Webpack CLI aims to offer users the ability to scaffold a fine-grained Webpack configuration with flexible support for custom templates. This will enable a number of powerful workflows, including the ability for other framework tooling to build on top of it to create SPAs and PWAs in a low-friction way.

This issue looks at ways in which we can continue to enable some of that work using Yeoman in tandem with the on-going V1 label.

Leveraging Yeoman’s generator system

On reviewing the work done on the Polymer CLI to enable the same user-installable custom template workflow, Webpack discovered several wins possible by switching over the CLI to using the Yeoman generator system under the hood.

Early prototypes of the Webpack CLI in fact shared similar functionality. It had a parser module which was circular that provided a scaffold through Inquirer the same way Yeoman would.

It was later discovered the behavior Even and the team really wanted was provided through the Yeoman helpers on top of Inquirer. This would provide flexibility in terms of extending the scaffolding - e.g composition support for tying together a scaffold with other Yeoman-based tools like a generator adding support for Babel to a project or even Preact.

This sets up the CLI for helping with a number of modern developer workflows. It could scaffold an optimized Webpack config with support for Progressive Web Apps. As the CLI deals with scaffolding through an AST, reading from an object inside the Yeoman generator can provide an entry point for code-splitting, Service Worker caching, favicon wiring, long-term caching and a number of other performance related features Webpack can offer.

Alpha/Beta for V1

The early versions of Webpack CLI may have templates that are a little more verbose, but will get slimmer as time goes on. In the future, Even and the team will be aiming to make it possible to integrate Webpack features on the fly (via AST transformations) to existing configurations.

There may also be the possibility of a webpack init scaffolding an extension of a Yeoman generator with some additional Webpack utility functions. This enables authors to not have to directly use the Webpack CLI to get a scaffold functional. It also means being able to support scaffolding outside CLI environments.

High-level next-steps:

CLI 🤖

• (Yeoman) PR for getArgument(). Enable making it easier to expose prompt answers to env.
• AST transformations for the init feature
• Move ASTs internally to webpack-addons and internal ASTs to Yeoman methods
• (Yeoman) Hook up functionality to the internal control flow
• Refactor logic in lib/creator post Yeoman switch
• (Yeoman) Use composeWith in order to mount other generators when you do: webpack-cli --init webpack-addons-ylvis webpack-addons-thefox
• Well reasoned add-ons story, carrying on from #42
• Minor issues on windows and prettier support, Enhancements: Picky work on init #111

Scaffolds 🏗

• Most basic Webpack CLI scaffold that works post Yeoman switch
• Webpack CLI scaffold for PWA: vendor + app code-splitting, long-term caching, SW caching. Heavily inspired by existing examples. Could also factor in #95.

Ecosystem 📦

• Coordinate with Jason Miller on Preact CLI usage of Webpack CLI under the hood
• An ecosystem for the init feature (by extending the Yeoman generator) - i.e ability to use Yeoman generators in other tools, improving the available helpers in both Webpack CLI and there that leverage max power for users in terms of AST part.

Docs 📚

• Webpack CLI getting started
• Webpack CLI API surface (post generator work)
• Webpack CLI PWA template

[addyosmani]

Webpack CLI scaffold for PWA

To give the thread a quick update on where we are here as we've mostly been chatting over DM 😊.
@ev1stensberg kindly prototyped an add-on using the output of https://github.com/vuejs/pwa as a POC just to kick the tires. We need to put together or figure out what the ideal Webpack output for this step would be. We've got a few options:

• Just the module bundling/serving parts that a PWA would need (we could say code-splitting, precaching, preloading (maybe), long-term caching). Stay very specific to what Webpack can do well here.

• Go for a more complete template that includes a framework. My hesitation here is that you start to compete with framework CLIs rather than telling the story of how they can build on top of Webpack CLI's scaffolding + AST handling for build pipeline stuff.

Leaning towards the first of these options. You could imagine the output not being too dissimilar to https://github.com/GoogleChrome/preload-webpack-plugin/blob/master/demo/webpack.config.js

[webpack-bot]

This issue had no activity for at least half a year.

It's subject to automatic issue closing if there is no activity in the next 15 days.

[webpack-bot]

Issue was closed because of inactivity.

If you think this is still a valid issue, please file a new issue with additional information.

[evenstensberg]

I'm closing this now 🎉 by CC-ing @developit . Feel free to reach out to us if you want to customize preact cli to eject configurations or to add additional functionality to preact-cli!