-
-
Notifications
You must be signed in to change notification settings - Fork 615
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feature: Enabling better extensibility & framework tooling integration #101
Comments
To give the thread a quick update on where we are here as we've mostly been chatting over DM 😊.
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 |
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. |
Issue was closed because of inactivity. If you think this is still a valid issue, please file a new issue with additional information. |
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! |
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 🤖
webpack-cli --init webpack-addons-ylvis webpack-addons-thefox
Scaffolds 🏗
Ecosystem 📦
Docs 📚
The text was updated successfully, but these errors were encountered: