At its heart, Greenwood is all about web standards. With the browser becoming such a powerful tool, especially with the advent of ECMAScript Modules (ESM) now having ubiquitous support in modern browsers, an entirely new workflow paradigm has emerged in which the browser can do more of the heavy lifting in our web dev workflows. In this way, less tooling and dependencies are needed to achieve excellent local development workflows as well as needing less overhead to maintain that stack.
Greenwood wants to take advantage of this opportunity to join in with other projects that are re-evaluating the landscape and thinking of a more unbundled world. One with less reliance on across the board bundling and transpilation, and one that just transforms on the fly only when needed. This paradigm lends itself really well to speedy local development workflows as well as benefiting end users who can be shipped more modern code. And for developers, now the code you write might actually look familiar while debugging in your browser!
To actually use Greenwood, users will interact with the Greenwood CLI. The CLI is what powers all the workflows available by Greenwood and builds your project for local development and production builds. It supports a configuration file that can be extended with plugin so that it can be extended to support additional workflows not intended to be maintained in core.
During development the CLI will:
importMapto avoid bundling.
E-Tagheaders to apply caching techniques for unchanged assets
For production builds:
Lastly, Greenwood aims to be a low point of friction as part of a standard development workflow. In this way, there will be a balance between what tools and dependencies are considered core to Greenwood. We aim to avoid the common "meta" framework paradigm and instead want to hone in on a lean and efficient core with good extension points for longer term maintainability and technical design.
The Greenwood CLI will aim to support development for all modern web standards and file types out of the box, in addition to markdown. Otherwise, Greenwood can be extended through plugins. In fact, Greenwood even maintains a few of its own plugins to help you get started! In this way the Greenwood team aims to keep a strong focus on a core experience that everyone will benefit from no matter what their building, while allowing a DIY / BYOP (bring your own plugin) workflow that anyone can use.
Greenwood aims to support all modern evergreen browsers out of the box and so advocates for a bundleless, untranspiled workflow by default. For when transpilation is needed (Babel, PostCSS), Greenwood recommends using an "evergreen build" approach that ensures that the code delivered to users is as modern as modern as possible, with the least amount of processing and transformations applied. Greenwood has two plugins that already supports this recommending by taking advantage of two a great tools; Browserslist and caniuse.com.
Using the above tools and leveraging their respective
env presets available, essentially, Browserlist will query CanIUse data to determine, based on the browser query provided, what features are / aren't needed for transpilation. This in turn allows Babel and PostCSS to intelligently transpile only what's needed for the features that are missing from the browser you are targeting, thus ensuring an "evergreen" experience for users and developers. Nice. 😎
So for example, a .browserslistrc that looks like this:
> 1% not op_mini all not ie 11
When run against the
browserslist, will in turn not transpile any modern code that all these browser support.
$ npx browserslist and_chr 67 and_uc 11.8 chrome 67 edge 17 firefox 61 ios_saf 11.3-11.4 ios_saf 11.0-11.2 safari 11.1