formidable-playbook

The Formidable Playbook
best practices frontend backend webpack


Summary

Project Name formidable-playbook Project Url https://github.com/FormidableLabs/formidable-playbook#readme
InceptionYear 2016-09-06 21:46:03 更新时间 2017-09-14 05:45:39
IssueManagement https://github.com/FormidableLabs/formidable-playbook/issues Licenses MIT
仓库地址 git+https://github.com/FormidableLabs/formidable-playbook.git 用户数 0
Node Engine 文件大小 38.5 KB
install build-md-toc build-wp-clean build-wp-lib build-wp-app build-wp build server lint check-uncommitted check check-ci

项目介绍

This is our playbook. It is the foundation that allows us to architect & design systems that move our client projects forward. In it, you will find practical approaches for building frontend & backend javascript applications. This is a living document, and we intend to share our knowledge as we continue to work towards making the web a better place. - [The Architecture Playbook](#the-architecture-playbook) - [Have a single infrastructure](#have-a-single-infrastructure) - [The Frontend Playbook](#the-frontend-playbook) - [Webpack plugins](#webpack-plugins) - [Start with good base plugins](#start-with-good-base-plugins) - [Code splitting](#code-splitting) - [Shared libraries](#shared-libraries) - [Scope Hoisting](#scope-hoisting) - [Tree shaking](#tree-shaking) - [Source maps](#source-maps) - [Babel plugins - In Progress](#babel-plugins---in-progress) - [Other tools - In Progress](#other-tools---in-progress) - [Performance auditing - In Progress](#performance-auditing---in-progress) - [The Backend Playbook - In Progress](#the-backend-playbook---in-progress) ## The Architecture Playbook #### [Have a single infrastructure](docs/infrastructure/single.md) A unified development effort should use a single infrastructure to control all similar projects. ## The Frontend Playbook Our frontend infrastructure is based around [webpack](https://webpack.github.io/) builds, but most of the guidelines / goals apply to any build tool. ### Webpack plugins #### [Start with good base plugins](docs/frontend/webpack-plugins.md) Webpack has a rich plugin ecosystem, including both [core](https://webpack.github.io/docs/list-of-plugins.html) and [open source modules](https://www.npmjs.com/browse/keyword/webpack-plugin). Webpack also has a straight forward interface to [write your own plugins](https://webpack.github.io/docs/plugins.html). A short list of plugin recommendations for best frontend performance include: | Plugin | Recommend? | Notes | | ------ | ---------- | ----- | | [`UglifyJsPlugin`](https://webpack.github.io/docs/list-of-plugins.html#uglifyjsplugin)| Yes | Minimize code | | [`DedupePlugin`](https://webpack.github.io/docs/list-of-plugins.html#dedupeplugin) | Yes for v1 | Collapse identical code chunks to a single reference | | [`OccurrenceOrderPlugin`](https://webpack.github.io/docs/list-of-plugins.html#occurrenceorderplugin) | Maybe for v1 | Reorder module and chunk ids by occurrence count | | [`DefinePlugin`](https://webpack.github.io/docs/list-of-plugins.html#defineplugin) | Maybe | Define constants for better optimization | | [`lodash-webpack-plugin`](https://github.com/lodash/lodash-webpack-plugin) | Maybe | Optimize `lodash` | #### [Code splitting](docs/frontend/webpack-code-splitting.md) [Code splitting](http://webpack.github.io/docs/code-splitting.html) is a Webpack feature that enables a JS bundle within a single build to be split up and loaded on-demand in smaller parts. Code splitting is appropriate within a single page and build. #### [Shared libraries](docs/frontend/webpack-shared-libs.md) Webpack shared libraries are slightly different from code splitting scenarios in that the common dependencies are shareable across builds and require a two-part build. In a first step, a common shared bundle and manifest is created. Then, in a second step, entry points ingest the manifest and omit any libraries included in the shared bundle. Shared libraries are appropriate for better long term caching within a single app across deploys and across different projects / real HTML pages. #### [Scope Hoisting](docs/frontend/webpack-scope-hoisting.md) Scope hoisted bundles try to place bundle modules into a global bundle scope so as to reduce the overhead of function calls for each bundled module. The problem and scope hoisting solutions are discussed in detail in Nolan Lawson's 2016 article ["The cost of small modules"](https://nolanlawson.com/2016/08/15/the-cost-of-small-modules/) #### [Tree shaking](docs/frontend/webpack-tree-shaking.md) [Tree shaking](http://www.2ality.com/2015/12/webpack-tree-shaking.html) is a transformation process for [ES6 modules](http://www.2ality.com/2014/09/es6-modules-final.html) whereby ESnext `export`s that are not used in a Webpack bundle can be isolated during code bundling and removed entirely by Uglify dead code elimination. #### [Source maps](docs/frontend/webpack-source-maps.md) The Webpack [SourceMapDevToolPlugin](http://webpack.github.io/docs/list-of-plugins.html#sourcemapdevtoolplugin) creates [source maps](https://github.com/ryanseddon/source-map/wiki/Source-maps:-languages,-tools-and-other-info) which allows a developer to view / debug developer-friendly source code instead of the optimized, mangled, and minified JS bundle of a frontend web app. Source maps should be enabled for both development and production. ### Babel plugins - In Progress ### Other tools - In Progress ### Performance auditing - In Progress ## The Backend Playbook - In Progress

开发依赖

GroupId ArtifactID Version 引用量
Sebastian McKenzie babel-core 6.26.3 1211
Sebastian McKenzie babel-eslint 10.0.3 88883
Luis Couto babel-loader 8.0.6 78433
Sebastian McKenzie babel-preset-es2015 6.24.1 660
Thorsten Lorenz doctoc 1.4.0 807
Nicholas C. Zakas eslint 6.8.0 188008
baer eslint-config-formidable 4.0.0 94
Stefan Lau eslint-plugin-filenames 1.3.2 773
Ben Mosher eslint-plugin-import 2.20.1 81471
bigbluehat http-server 0.12.1 5620
Ryan Roemer webpack-stats-plugin 0.3.1 209