Name: cli-build-widget
Owner: Dojo
Description: Command for building Dojo 2 widgets
Created: 2018-01-15 19:51:24.0
Updated: 2018-05-04 13:31:46.0
Pushed: 2018-05-04 13:31:44.0
Homepage: null
Size: 7698
Language: JavaScript
GitHub Committers
| User | Most Recent Commit | # Commits |
|---|
Other Committers
| User | Most Recent Commit | # Commits |
|---|
The official CLI command for building Dojo 2 custom elements.
To use @dojo/cli-build-widget in a single project, install the package:
install @dojo/cli-build-widget
@dojo/cli-build-widget is an optional command for the @dojo/cli.
By default widgets are built using an evergreen configuration, meaning that the build process:
.mjs modules over .js modules{ target: 'es6', module: 'esnext' } Typescript compiler optionschrome flag from dojo/webpack-contribA custom elements project is expected to have the following directory and file structure:
custom-element-parent/
customElementParent.m.css
CustomElementParent.ts
custom-element-child/
customElementChild.m.css
CustomElementChild.ts
s/
unit/
functional/
orc
There are three modes available to build Dojo 2 custom elements: dist, dev and test. The mode required can be passed using the --mode flag:
build widget --mode dist
The built custom element files are written to the output/{mode selected} directory. The output mirrors the src directory, so if a custom element is located at src/custom-element/CustomElement.s, the built element will be output to output/{mode}/custom-element/CustomElement.js.
Note: dist is the default mode and so can be run without any arguments, dojo build widget.
The dist mode creates a production ready build.
The dev mode creates a build that has been optimized for debugging and development.
The test mode creates bundles that can be used to run the unit and functional tests for the custom element(s).
A web server can be started with the --serve flag. By default, the build is served on port 9999, but this can be changed with the --port (-p) flag:
ild once and then serve on port 3000
build -s -p 3000
Building with the --watch option observes the file system for changes, and recompiles to the appropriate output/{dist|dev|test} directory, depending on the current --mode. When used in the conjunction with the --serve option and --mode=dev, --watch=memory can be specified to enable automatic browser updates and hot module replacement (HMR).
build -w # start a file-based watch
build -s -w=memory -m=dev # build to an in-memory file system with HMR
The path for elements to build can be provided using the repeating options --elements or -e:
build -e src/custom-element-child/CustomElementChild -e src/custom-element-parent/CustomElementParent
To build custom elements for legacy environments use the --legacy or -l flag. Custom elements built with the legacy flag will need to include the polyfill for the native shim.
Ejecting @dojo/cli-build-widget will produce the following files under the config/build-widget directory:
build-options.json: the build-specific config options removed from the .dojorcejected.config.js: the root webpack config that passes the build options to the appropriate mode-specific config based on the --env.mode flag's value.base.config.js: a common configuration used by the mode-specific configs.dev.config.js: the configuration used during development.dist.config.js: the production configuration.test.config.js: the configuration used when running tests.As already noted, the dojorc's build-widget options are moved to config/build-widget/build-options.json after ejecting. Further, the modes are specified using webpack's env flag (e.g., --env.mode=dev), defaulting to dist. You can run a build using webpack with:
_modules/.bin/webpack --config=config/build-widget/ejected.config.js --env.mode={dev|dist|test}
Custom element projects use a .dojorc file at the project root to control various aspects of development such as testing and building. This file is required to build custom elements, it MUST be valid JSON, and it MUST provide at least an elements array with the custom element paths. All other values are options. The following options can be used beneath the "build-widget" key:
elements: string[]Contains paths relative to the project root to the custom elements that should be built.
"build-widget": {
"elements": [
"src/menu-item/MenuItem",
"src/menu/Menu"
]
}
bundles: objectUseful for breaking a build into smaller bundles, the bundles option is a map of webpack bundle names to arrays of modules that should be bundled together. For example, with the following configuration both src/Foo and src/Bar will be grouped in the foo.[hash].js bundle:
"build-widget": {
"bundles": {
"foo": [
"src/Foo",
"src/Bar"
]
}
}
features: objectA map of has features to boolean flags that can be used when building in dist mode to remove unneeded imports or conditional branches. See the static-build-loader documentation for more information.
We appreciate your interest! Please see the Dojo 2 Meta Repository for the Contributing Guidelines. This repository uses prettier for code style and is configured with a pre-commit hook to automatically fix formatting issues on staged .ts files before performing the commit.
To start working with this package, clone the repository and run npm install.
In order to build the project run grunt dev or grunt dist.
Builds a new test artifact from the repository source code and re-installs the test-app dependencies before running all unit and functional tests.
Builds and packages cli-build-widget as dojo-cli-build-widget.tgz in the dist directory.
Re-generates the test fixtures in test-app. Assumes that the dependencies have been installed for the test project.
Runs prettier on all .ts files in the src and tests directories, this will fix any detected code style violations.
Generates a test release tarball that can be used as a drop-in dependency for testing changes with a custom elements project. WARNING This modifies package-lock.json, so be careful to undo the changes (git checkout -- package-lock.json) after running this script. See Workflow for custom package releases for more information.
Test cases MUST be written using Intern using the BDD test interface and Assert assertion interface.
90% branch coverage MUST be provided for all code submitted to this repository, as reported by istanbul?s combined coverage results for all supported platforms.
The command is tested by running via the Dojo CLI and asserting the build output against known fixtures. To do this, a test artifact needs to be built and installed into the test-app:
test
Once the test artifact has been installed, if there have been no changes to the command code grunt test can be used to repeat the tests.
© 2018 JS Foundation. New BSD license.