Our Workspace (Requires UW Health intranet access)
gulp-cli)
npm install --global gulp-cli from the command line after Node has been installed.cd to the Framework’s directory.yarn and wait for the dependencies to install.
npm install is also acceptable but could have versioning issues.gulp.The style guide is generated on the fly by the gulp task styleGuide (using the markdown-styleguide-generator node module).
To create style guide entries, create a comment block with the SG in the first line. The next immediate line should be title of your style guide entry (using a # to demarcate the start). A / will indicate a sub-section title. So #Title/Sub-section will create a parent section named “Title”, with a child named “Sub-section”.
Create html examples (with a code snippet) by creating a code block followed by “html_example” (```html_example).
Separating “development” comments from “styles” requires adding a [[dev]] anywhere within the title of that section.
/* SG
# Section/Component
This is an example Component.
```html_example
<div>...</div>
```
* /
Everything will be run through Markdown (GitHub Flavored). This allows text formatting and code samples.
Running gulp by itself will compile your Sass and concatenate your Javascript, but you may need some additional build steps for a complete workflow. Our gulp file accepts arguments in the form of gulp --argument1 --argument2 to turn certain tasks on and off.
Production mode:
Running gulp --production will run all tasks in production mode, and set the NODE_ENV to 'production'. This will make sure all files are in shape to be shipped to a production server (minified, concatenated, uglified, etc.).
“Local Production” mode:
gulp --local will run the project in what we call “local production” mode. This means all assets are run through the production build steps while still being watched and served over a local server. This mode is really only for quick tests as it can be extremely slow.
No Style Guide:
Running gulp --no-sg will prevent style guide generation. This can be useful if you are simply working on styles only since the style guide forces a page reload.
Most of our “dot” files live here. Our build entry points (gulpfile and webpack.config) also live here for convention’s sake. These two ultimately pull their dependencies from the bin folder.
Contains all uncompiled files. Files should be organized by function, not file type wherever possible. For instance, _src/components contains component folders with javascript, templates, and sass mixed together. Our build process allows for these types of files to live anywhere.
_src/sass/ & _src/js/ Sometimes generalized functions and libraries just don’t fit under tangible functional locations. In this case, we keep them in these file-type folders.
_src/static/
All simple assets live here. Typically, these assets require nothing more than to be copied to another location (images being an exception). These files will just be copied to dist, nearly untouched by the build process.
_src/_samples/
Development-only “sample” pages. Any JS file here will be compiled by webpack, and output under dist/samples/[filename]/index.html. These should be used for development only and not ship with the final production. In fact, “production” mode will not these files.
Build scripts and configuration.
console.log-type output.Additional documentation about the project.
The build target. This folder should never contain pre-built files, since its contents are emptied on every build. This is also the folder that gets served up by the the local server.