Code Monkey home page Code Monkey logo

uswds-compile's Introduction

United States Web Design System

CircleCI Build Status Snyk vulnerabilities npm Version npm Downloads GitHub issues code style: prettier

The United States Web Design System includes a library of open source UI components and a visual style guide for U.S. federal government websites.

This repository is for the design system code itself. We maintain another repository for the documentation and website. To see the design system and its documentation on the web, visit https://designsystem.digital.gov.

Contents

Recent updates

Information about the most recent release of the design system can always be found in the release history. We include details about significant updates and any backward-incompatible changes along with a list of all changes.

USWDS 3.0 is our most recent major release.

Getting started

We’re glad you’d like to use the design system — here’s how you can get started:

What's included in USWDS

The USWDS package includes compiled assets in a dist directory and component source files in a packages directory.

As of USWDS 3.0.0, our codebase is centered around functional packages, typically components. For more about how we organize packages, see our Packages documentation. In each of the following examples, we use [package] to represent a specific package. For example, component Sass is located in packages/[package]/src/styles for an accordion, this would be packages/usa-accordion/src/styles.

  • Fonts are located in both dist/fonts and packages/uswds-core/src/assets/fonts. The fonts in dist are simply a copy of the files in uswds-core.
  • Images and icons are located in: dist/img. The source for component-specific images can be found in a package's src/img directory.
  • JavaScript for components is located in packages/[package]/src/index.js. General JavaScript utilities and polyfills are located in the uswds-core package: packages/uswds-core/src/js
  • Sass component-specific stylesheets are located in: packages/[package]/src/styles. Many components also have a component entry point at packages/[package]/_index.scss that includes references to all a component's dependencies as well. Compiled CSS is located in dist/css.
  • Template markup for the components is located in: packages/[package]/src/[package.twig] in the site root. These, however, are written in the templating language Twig. It's best to get HTML source markup directly from designsystem.digital.gov/components

Directory structure

Here's what you can expect to find inside the USWDS package:

[uswds package]
├── .storybook/
├── dist/
│   ├── css/
│   │   ├── uswds.css
│   │   ├── uswds.min.css
│   │   └── uswds.min.css.map
│   ├── fonts/
│   │   ├── merriweather/
│   │   ├── public-sans/
│   │   ├── roboto-mono/
│   │   └── source-sans-pro/
│   ├── img/
│   │   ├── usa-icons/
│   │   ├── material-icons/
│   │   ├── uswds-icons/
│   │   ├── usa-icons-bg/
│   │   ├── sprite.svg
│   │   ├── [individual images]
│   │   ...
│   ├── js/
│   │   ├── uswds-init.js
│   │   ├── uswds-init.min.js
│   │   ├── uswds-init.min.js.map
│   │   ├── uswds.js
│   │   ├── uswds.min.js
│   │   └── uswds.min.js.map
│   ├── scss/
│   │   └── stylesheets/
│   │       └── uswds.scss
│   └── theme/
│       ├── _uswds-theme.scss
│       ├── _uswds-theme-custom-styles.scss
│       └── styles.scss
├── packages/
│   ├── usa-component/
│   │   ├── src/
│   │   │   ├── content/
│   │   │   ├── styles/
│   │   │   │   ├── _index.scss
│   │   │   │   └── component.scss
│   │   │   ├── test/
│   │   │   │   ├── component.spec.js
│   │   │   │   └── template.html
│   │   │   ├── index.js
│   │   │   ├── usa-component.stories.js
│   │   │   └── usa-component.twig
│   │   └── _index.scss_/
│   ├── usa-component/
│   ├── usa-component/
│   ├── uswds-bundle/
│   ├── uswds-bundle/
│   ...
├── src/
│   ├── img/
│   ├── stylesheets/
│   └── test/
└── tasks/

Package contents

Here's what you can expect to find in each of the directories and files in the USWDS package:

  • /.storybook: Storybook configuration files (not used in USWDS projects)

  • /dist: Compiled or collected files

  • /dist/css: Precompiled CSS files with USWDS defaults

  • /dist/fonts: Default fonts available to the design system

  • /dist/img: All USWDS images collected into a single directory

  • /dist/img/usa-icons: All icons collected into the USWDS icon sprite (sprite.svg)

  • /dist/img/material-icons: All Material Icons

  • /dist/img/uswds-icons: All icons created by USWDS

  • /dist/img/sprite.svg: Precompiled icon sprite with default icon set

  • /dist/js: Precompiled JavaScript files

  • /dist/scss/stylesheets/uswds.scss: Backwards compatible USWDS Sass entry point

  • /dist/scss/theme: Example theme files

  • /dist/scss/theme/_uswds-theme.scss: Example theme settings file

  • /dist/scss/theme/_uswds-theme-custom-styles.scss: Example custom settings file

  • /dist/scss/theme/styles.scss: Example project Sass entry point

  • /packages: Source files for USWDS components and other functionality.

  • /packages/usa-[component]: Each package has a name like usa-[component] that matches its class name in the design system, like usa-accordion.

  • /packages/usa-[component]/_index.scss: Sass entry point for the package.

  • /packages/usa-[component]/src: Package source files

  • /packages/usa-[component]/src/index.js: Package javascript

  • /packages/usa-[component]/src/usa-component.stories.js: Storybook setup

  • /packages/usa-[component]/src/usa-component.twig: Component template

  • /packages/usa-[component]/src/index.js: Package javascript

  • /packages/usa-[component]/src/content: Package template content

  • /packages/usa-[component]/src/test: Package unit tests

  • /packages/usa-[component]/src/styles: Package source Sass

  • /packages/uswds: The package most projects include by default. This bundle includes all USWDS components and functionality.

  • /packages/uswds-[bundle]: Other non-component functionality is included in uswds--prefixed packages. These bundles might collect common component packages (uswds-form-controls) or important internal functionality (uswds-core).

  • /src: Placeholders included for backwards compatibility. Most projects should avoid using the contents of this directory.

  • /tasks: Internal build process files (not used in USWDS projects)

Installing the design system

There are two ways to install the design system on a project:

  • Installing it as a project dependency using Node and npm
  • Installing the package directly from GitHub

We recommend using npm to make it as straightforward as possible to install the design system and update it as we release new versions.

Install using Node and npm

Use the npm package manager for Node-based projects. USWDS maintains the @uswds/uswds package that includes both the pre-compiled and compiled files. We rely on npm packages to easily update and install the design system from the command line.

  1. Install Node/npm. Below is a link to find the install method that coincides with your operating system:

    Note for Windows users: If you are using Windows and are unfamiliar with Node or npm, we recommend following Team Treehouse's tutorial for more information.

  2. Make sure you have installed it correctly:

    npm -v
    6.13.0 # This line may vary depending on what version of Node you've installed.
  3. Create a package.json file. You can do this manually, but an easier method is to use the npm init command. This command will prompt you with a few questions to create your package.json file.

  4. Add @uswds/uswds to your project’s package.json:

    npm install --save @uswds/uswds@latest

The @uswds/uswds module is now installed as a dependency. You can use the compiled files found in the node_modules/@uswds/uswds/dist/ directory or the source files in the node_modules/@uswds/uswds/packages/ directory.

Note: We do not recommend directly editing the design system files in node_modules. One of the benefits of using a package manager is its ease of upgrade and installation. If you make customizations to the files in the package, any upgrade or re-installation will wipe them out.

Install the package directly from GitHub

If you’re using a framework or package manager that doesn’t support npm, you can find the source files in this repository and use them in your project. Otherwise, we recommend that you follow the steps outlined in this section.

  1. Download the USWDS package directly from the latest USWDS release and uncompress that file.

  2. Copy these files and folders into a relevant place in your project's code base. Here is an example structure for how this might look:

    example-project/
    ├── assets/
    │   ├── uswds/
    │   │   ├── dist/
    │   │   ├── packages/
    │   │   └── src/
    │   ├── stylesheets/
    │   ├── images/
    │   └── javascript/
    └── index.html
    

    You'll notice in our example above that we also outline a stylesheets, images and javascript folder in your assets folder. These folders are to help organize any assets that are unique to your project and separate from the design system assets.

    Note: Files in the downloadable USWDS package will show a "last modified" date of October 26, 1985. This is intentional. This default date is set by npm on all its packages to ensure builds will be identical.

Using USWDS CSS and JavaScript in your project

The three files critical to any USWDS project are the stylesheet, the JavaScript, and the initializer. Most projects require all of these to function properly.

  • Stylesheet: This is the compiled CSS stylesheet that describes how design system components look. To start, reference either uswds.css or uswds.min.css in the <head> of your document. Find this file in /dist/css. Most projects will want to compile their own CSS from USWDS source Sass instead of using the precompiled version. For more about this, see Compiling USWDS Sass into CSS, below.
  • Library: This is the compiled JavaScript that controls component interactivity. Reference either uswds.js or uswds.min.js at the end of the <body> of your document. Find this file in /dist/js.
  • Initializer: This small JavaScript file (less than 1 KB minified) helps the browser know if the USWDS JavaScript library is loading properly. This prevents component content from "flashing" or "shifting" while the page loads. Reference uswds-init.min.js in the <head> of your page, or inline its contents directly into the <script> tag. Find this file in /dist/js.

Reference the stylesheet, library, and initializer in each HTML page or dynamic template in your project.

Here is an example of how to reference these assets in your index.html file:

<!DOCTYPE html>
<html>
  <head>
    <meta charset="utf-8" />
    <meta http-equiv="X-UA-Compatible" content="IE=edge" />
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>My Example Project</title>
    <script src="assets/uswds/dist/js/uswds-init.min.js"></script>
    <link rel="stylesheet" href="assets/uswds/dist/css/uswds.min.css" />
  </head>
  <body>
    <script src="assets/uswds/dist/js/uswds.min.js"></script>
  </body>
</html>

And that’s it — you should now be able to copy our code samples into your index.html and start using the design system.

Compiling USWDS Sass into CSS

If you want to take full advantage of USWDS custom settings and add build new styles and components with the USWDS toolset, you'll need a way to access the assets in the USWDS package and compile custom CSS from the USWDS source files.

USWDS uses the task manager Gulp as a way to add USWDS assets to a project and compile our CSS from the package source. Gulp is a useful and powerful tool, but it can be difficult to set up if you are new to it.

The USWDS Compile package is made for developers new to Gulp or those who just want a simple setup to compile USWDS Sass. The repo contains files and instructions for setting up the compiler, initializing USWDS, and compiling CSS from the source files.

Sass compilation requirements

USWDS Sass needs three things to compile properly:

  • Sass Module syntax: USWDS requires a modern Sass compiler that can parse Sass Module syntax.
  • Autoprefixing: USWDS requires Autoprefixing your CSS with a specific .browserslistrc.
  • Sass Load Paths: USWDS requires Sass compilers use Load Paths that reference the /packages directory in the USWDS package

Note: Using a compiler package like USWDS Compile is a good way to fulfill these requirements automatically.

Autoprefixing

The design system requires autoprefixing to work properly. Don't add vendor prefixes to your custom styles manually — it is more reliable to use autoprefixing. Autoprefixing services like gulp-autoprefixer automatically add vendor prefixes to CSS rules. We use the following autoprefixer settings via .browserslistrc config:

> 2%
last 2 versions
IE 11
not dead

Sass Load Paths

USWDS 3.0 and newer require the use of Sass Load Paths to compile properly.

USWDS 3.0 load paths must include a path to the /packages directory in the USWDS package, typically by updating an IncludePaths setting to include node_modules/@uswds/uswds/packages.

Here's how this might look in Gulp and in Webpack:

Gulp
.pipe(
  sass({
    includePaths: [
      "./node_modules/@uswds/uswds/packages",
    ],
  })
Webpack
loader: "sass-loader",
options: {
  sassOptions: {
    includePaths: [
      "./node_modules/@uswds/uswds/packages"
    ],
  },
},

Other useful compiler postprocessing

  • Minification: We recommend using a minifier like csso to compress your final compiled CSS.
  • Sourcemaps: We recommend using a sourcemap tool like gulp-sourcemaps to assist debugging by keeping track of source Sass locations.

Sass and theme settings

The design system is customizable using the power of Sass (Syntactically Awesome Style Sheets). The critical files you'll need in your project are those in dist/scss/theme:

  • _uswds-theme.scss: custom theme settings
  • _uswds-theme-custom-styles.scss: additional project CSS for customizing or adding to what USWDS provides
  • styles.scss: The Sass entry point. This is the primary Sass file that you'll compile. It collects theme settings, USWDS source files, and custom CSS

styles.scss looks something like the following code. It adds all the project theme settings, then adds USWDS source, and finally adds your project's custom styles:

@forward "uswds-theme";
@forward "uswds";
@forward "uswds-theme-custom-styles";

Technical note: The @forward 'uswds' statement above references the uswds package in node_modules/@uswds/uswds/packages. The compile functions included in uswds-compile automatically look for USWDS packages in the proper directory using includePaths.

JS customization

Unfortunately, customizing the JavaScript for the USWDS currently requires NodeJS and a module bundler like Browserify or Webpack. We apologize for this inconvenience, and are working to resolve it in a future release of the design system.

USWDS JavaScript is separated into components (just as with the CSS and HTML) and initialized with event handlers when the DOM is ready. These components are accessible as CommonJS modules that can be required in other JavaScript files, then built for the browser. The components are not accessible in the global browser scope, but can be extended to be included by requiring components and setting it to a global scope:

window.uswds = require("./components");

Each component has a standardized interface that can be used to extend it further. The components store a HTML class (like .usa-accordion__button[aria-controls]) used to link HTML elements with the JavaScript component. When a component is initialized, it searches through the current HTML DOM to find all elements that match the class and initializes the component JavaScript for those elements. The primary methods for each component include:

  • on: Initialize a component's JavaScript behavior by passing the root element, such as window.document.
  • off: The opposite of on, de-initializes a component, removing any JavaScript event handlers on the component.
  • hide: Hide the whole component.
  • show: Shows a whole, hidden component.
  • toggle: Toggles the visibility of a component on and off based on the previous state.

Some components have additional methods based on that component's functionality. Any additional methods are found in that component's JavaScript file.

If you’re using a modern framework like React or Angular you can import components and initialize them in your library's DOM ready lifecycle event.

Importing a modular component.

import USWDS from "@uswds/uswds/js";
const { characterCount, accordion } = USWDS; // deconstruct your components here

// Alternatively
import accordion from "@uswds/uswds/js/usa-accordion";

⚠️Requires webpack 5+

React hooks example:

function App() {
  const ref = document.body;

  useEffect(() => {
    // initialize
    characterCount.on(ref);
    // default ref is document.body, if you want to use
    // default you do not have to pass arguments
    accordion.on();

    // remove event listeners when the component un-mounts.
    return () => {
      characterCount.off();
      accordion.off();
    };
  });
}

Angular example:

export class App implements OnInit {
  constructor() {
    this.ref = document.body;
    // default ref is document.body, if you want to use
    // default you do not have to pass arguments
  }

  ngOnInit() {
    // initialize
    characterCount.on(this.ref);
    accordion.on();
  }

  // remove event listeners when the component un-mounts.
  ngOnDestroy() {
    characterCount.off();
    accordion.off();
  }
}

Style theming and tokens

USWDS 3.0 provides extensive support for theming via its theme settings files introduced in Sass and theme settings, above.

Set theme settings with USWDS design tokens, not with values directly. They tend to be quoted strings like 'desktop' or 'md' or unitless numbers like 2 or -1.5. Tokens are the values passed into the USWDS functions and mixins that parse them. They are the keys that, through the mechanism of a function or mixin, unlock a value — they are not the values themselves.

Visit the Design tokens section of USWDS 3.0 documentation for more on the available tokens for color, spacing units, font size, and more.

Using tokens in theme settings

The following is an example of theme settings from _uswds-theme.scss:

@use "uswds-core" with (
  $theme-grid-container-max-width: "desktop",
  $theme-site-margins-breakpoint: "desktop",
  $theme-site-margins-width: 4,
  $theme-site-margins-mobile-width: 2,
)

The USWDS uses those tokens to build component styles:

.usa-example {
  @include u-padding-x($theme-site-margins-mobile-width);
  max-width: units($theme-grid-container-max-width);

  @include at-media($theme-site-margins-breakpoint) {
    @include u-padding-x($theme-site-margins-width);
  }
}

This is the functional equivalent of:

.usa-example {
  @include u-padding-x(2);
  max-width: units("desktop");

  @include at-media("desktop") {
    @include u-padding-x(4);
  }
}

Which, if $theme-respect-user-font-size is set to true would output something like:

.usa-example {
  padding-left: 1rem;
  padding-right: 1rem;
  max-width: 64rem;
}

@media screen and (min-width: 64em) {
  .usa-example {
    padding-left: 2rem;
    padding-right: 2rem;
  }
}

In general, USWDS sets variables with tokens, and passes those variables into functions and mixins in the source Sass.

Set the base asset paths (fonts and images)

The values of $theme-font-path and $theme-image-path will be appended to USWDS font paths and image paths, respectively:

@use "uswds-core" with (
  $theme-font-path: "../fonts",
  $theme-image-path: "../img",
);

CSS architecture

  • The CSS foundation of this site is built with the Sass preprocessor language.
  • The CSS organization and naming conventions follow 18F’s Engineering Guide.
  • We format our code with Prettier, per the formatting section of the 18F Engineering Guide.
  • CSS selectors are prefixed with usa (For example: .usa-button). This identifier helps the design system avoid conflicts with other styles on a site which are not part of USWDS.
  • Uses a BEM approach for naming CSS selectors. Blocks are separated from elements with two underscores (__). Multi-word blocks use single hyphens instead of spaces. Modifier classes are additive — proper markup requires the base class and the modifier class or classes. Modifier classes consist of the base class plus a modifier suffix, separated by two hyphens (--) as in .usa-button.usa-button--secondary or usa-accordion.usa-accordion--bordered.
  • Uses modular CSS for scalable, modular, and flexible code.
  • Uses nesting when appropriate. Nest minimally with up to two levels of nesting.
  • Hard-coded magic numbers are avoided.
  • Media queries are built mobile first.
  • Spacing units are set with the units() function as described in the USWDS 3.0 documentation. In general, we use spacing in multiples of 8px — expressed as a multiple in units([multiple]). For instance units(2) is the equivalent of 2 * 8px or 16px. In the final, compiled CSS, this value will be expressed in rem, as a multiple of the base font size set with $theme-base-font-size.

For more information, visit: 18F’s CSS Guide

Browser support

We’ve designed the design system to support older and newer browsers through progressive enhancement. The current major version of the design system (3.0.0) follows the 2% rule: we officially support any browser above 2% usage as observed by analytics.usa.gov. Currently, this means that the design system version 3.0.0 supports the newest versions of Chrome, Firefox, and Safari.

As of USWDS 3.0.0 we no longer officially support Internet Explorer 11 (IE11). We will continue to include IE11 polyfills and prefixing for the first few releases in USWDS 3.x — when we finally drop IE11, we'll make a note in the release notes and in this documentation.

Accessibility

The design system also meets the WCAG 2.0 AA accessibility guidelines and conforms to the standards of Section 508 of the Rehabilitation Act. Additionally, we try to meet the requirements of WCAG 2.1.

We use the following tools to ensure USWDS is accessible:

If you find any issues with our accessibility conformance, please create an issue in our GitHub repo or send us an email at [email protected]. We prioritize accessibility issues. See the Accessibility page of our website for more information.

Long-term support of v1.x

Version 1.x is no longer maintained.

Long-term support of v2.x

Version 2.x is in maintenance mode and will continue to get important bugfixes and security patches until May 2023.

Need installation help?

Do you have questions or need help with setup? Did you run into any weird errors while following these instructions? Feel free to open an issue here:

https://github.com/uswds/uswds/issues.

You can also email us directly at [email protected].

Contributing to the code base

For complete instructions on how to contribute code, please read CONTRIBUTING.md. These instructions also include guidance on how to set up your own copy of the design system style guide website for development.

If you would like to learn more about our workflow process, check out the Workflow and Issue label Glossary pages on the wiki.

If you have questions or concerns about our contributing workflow, please contact us by filing a GitHub issue or emailing our team.

Reuse of open-source style guides

Much of the guidance in USWDS leans on open source designs, code, and patterns from other civic and government organizations, including:

Licenses and attribution

A few parts of this project are not in the public domain. Attribution and licensing information for those parts are described in detail in LICENSE.md.

The rest of this project is in the worldwide public domain, released under the CC0 1.0 Universal public domain dedication.

Contributing

All contributions to this project will be released under the CC0 dedication alongside the public domain portions of this project. For more information, see CONTRIBUTING.md.

uswds-compile's People

Contributors

amyleadem avatar buckaroogeek avatar danielnaab avatar dependabot[bot] avatar jaredcunha avatar jfredrickson avatar kdimatteo avatar kognise avatar mahoneycm avatar mejiaj avatar thisisdano avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar

uswds-compile's Issues

Icons: Allow for custom icon directory

Problem

As a developer, I'd like to have an option to track icon changes more easily.

Currently I can only set uswds.paths.dist.img, this directory performs two functions:

  1. Tells Compile where to import USWDS images
  2. Looks for {{ uswds.paths.dist.img }}/usa-icons/**/*.svg to build the sprite

This means on gulp init I'll get hundreds of file changes unless I add these images to gitignored directory.

⚠️ Ignoring directories prevents me from tracking changes to my sprite. Because they'll be lost on npx gulp copyAssets on a circleci build (like uswds-site).

Solution

What I'd like to see is a setting maybe uswds.paths.dist.icons that will also watch that directory for changes and add them to the already compiled sprite.

Additionally

It would be great to have the additional option of deciding where to only use this directory or combine it with usa-icons

Should paths.src.projectSass be used in buildSass?

I setup my new repo with

uswds.paths.dist.fonts = './assets/fonts';
uswds.paths.dist.img = './assets/img';
uswds.paths.dist.js = './assets/js';
uswds.paths.dist.theme = './components/00-uswds';

uswds.paths.src.projectIcons = './images/**';

uswds.paths.src.projectSass = './components';

I want the sass files outputted to 00-uswds just once during init (per the recommendation) then when I build I want everything to compile in our components folder. but it appears to only look at 00-uswds.

I had to change the variable post init for it to work.

USWDS-Compile - Feature: Allow users to define SASS output style

Is your feature request related to a problem? Please describe.

Giving users the option of output style of SASS (minified vs unminified) could help improve debugging when prototyping and final CSS when shipping.

Describe the solution you'd like

Users can select whether they want minified or unminified CSS.

Describe alternatives you've considered

Output both minified and unminified and user can use either.

Additional context

Related to #79.

Code of Conduct

USWDS-Compile - Bug: Incorrect relative image paths in compiled styles

Describe the bug

Running uswds-compile with a customuswds.paths.src.theme setting produces a styles.css with invalid path values for background-image

Running uswds-compile without a custom uswds.paths.src.theme settings produces the expected result

Steps to reproduce the bug

  • install @uswds/uswds-compile
  • use a default gulpfile.js
const uswds = require("@uswds/compile");

uswds.settings.version = 3;
uswds.paths.src.theme = "src/theme";
uswds.paths.dist.theme = "src/theme";
exports.init = uswds.init;
exports.compile = uswds.compile;
  • run gulp init
  • look at output in /assets, the directory structure is
assets
 |__ uswds
        |__ css
        |__ fonts
        |__ img
        |__ js

the file at assets/uswds/css/styles.css sets background-image values with paths like url(../uswds/img/usa-icons/launch.svg); which is an incorrect relative URL. The url set for fonts is the correct relative URL

Expected Behavior

the output at /assets/uswds/css/styles.css uses relative paths like url(../img/usa-icons/launch.svg);

Related code

No response

Screenshots

Screenshot 2023-11-22 at 10 05 36 AM Screenshot 2023-11-22 at 10 05 44 AM Screenshot 2023-11-22 at 10 40 50 AM

System setup

@uswds/compile - 1.0.0
@uswds/uswds - 3.7.0
MacOS

Additional context

No response

Code of Conduct

USWDS-Compile - Feature: How can I create separate component directories?

Is your feature request related to a problem? Please describe.

The problem is that all my CSS is loaded for all pages, including pages where the CSS isn't relevant. Currently in my gulpfile.js, I have these paths:

uswds.paths.dist.css = './css';
uswds.paths.dist.theme = './sass';

This works as expected. But now I want to create subdirectories for components, like /sass/component/my-component/my-component.scss.

Describe the solution you'd like

I want to create subdirectories for components, like /sass/component/my-component/my-component.scss

Note: I do not want my-component.scss automatically compiled into my /css/style.scss. Instead, I want it to compile somewhere like /css/my-component/my-component.css. That way my application can load my-component.css only where it is relevant.

Describe alternatives you've considered

No response

Additional context

I'm not sure if I'm looking for a support in the right place. I don't know if my issue is a more general gulp question -- and I should get support somewhere like stackoverflow.com -- or if my issue is specific to uswds-compile.

Code of Conduct

gulpfile.js uswds.paths.dist.* path settings not honored

Describe the bug

When I attempt to customize USWDS settings by editing gulpfile.js to configure path settings (e.g., uswds.paths.dist.img), it causes an error because the path specified is not used.

Steps to reproduce the bug

Install USWDS and USWDS Compile
Run npx gulp init to install the initial USWDS Compile files, initially not changing any paths and test. You should see no errors in the developer console, and the images rendered and appropriate fonts used.

mkdir uswds-test
cd uswds-test
npm init -y
npm install express --save
npm install @uswds/uswds --save
npm install @uswds/compile --save-dev
vi gulpfile.js
npx gulp init
vi index.html
vi server.js
node server.js

Then delete any generated files (assets and sass) and try changing the paths to differ from the default generated paths, run npx gulp init again, update the path to styles.css in index.html, and re-test. You will see errors in the browser console where the images, fonts etc are not found due to uswds looking for them in unexpected places.

Examples

Use something other than img for the dist.img path

// generates where specified but fails
// (looks for images in src/assets/uswds/img)
uswds.paths.dist.theme = './src/sass/uswds';
uswds.paths.dist.img =   './src/assets/uswds/images';
uswds.paths.dist.fonts = './src/assets/uswds/fonts';
uswds.paths.dist.js =    './src/assets/uswds/js';
uswds.paths.dist.css =   './src/assets/uswds/css';

Use something other than fonts for the dist.font path

// generates where specified but fails
// (looks for fonts in src/assets/uswds/fonts)
uswds.paths.dist.theme = './src/sass/uswds';
uswds.paths.dist.img =   './src/assets/uswds/img';
uswds.paths.dist.fonts = './src/assets/uswds/font';
uswds.paths.dist.js =    './src/assets/uswds/js';
uswds.paths.dist.css =   './src/assets/uswds/css';

Use only the two settings given in the documention as an example, with a slight change to use src since frameworks do not allow serving content outside of the src dir.

// generates
// assets/uswds/{fonts,img,js}
// src/assets/uswds/css
// src/sass/uswds
//
// But fails to load fonts (expects them to be in src/assets/uswds/fonts)
uswds.paths.dist.css =   './src/assets/uswds/css';
uswds.paths.dist.theme = './src/sass/uswds';

I did not try changing dist.js or dis.css to other endings, but you get the idea.

Expected Behavior

The paths specified in gulpfile.js are used and work.

Test files used

gulpfile.js

/**
* Import uswds-compile
*/
const uswds = require("@uswds/compile");

/**
* USWDS version
* Set the major version of USWDS you're using
* (Current options are the numbers 2 or 3)
*/
uswds.settings.version = 3;

/**
* Path settings
* Set as many as you need
*/
//uswds.paths.dist.css = './assets/css';
//uswds.paths.dist.theme = './sass/uswds';

/**
* Exports
* Add as many as you need
*/
exports.init = uswds.init;
exports.compile = uswds.compile;
exports.watch = uswds.watch;

index.html

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8">
  <meta name="viewport" content="width=device-width, initial-scale=1.0">
  <meta http-equiv="X-UA-Compatible" content="ie=edge">
  <link rel="stylesheet" href="src/assets/uswds/css/styles.css">
  <title>USWDS Test</title>
</head>
<body>
  <div class="ui container">
    <h1>Test</h1>

    <div class="usa-alert usa-alert--info">
      <div class="usa-alert__body">
        <h4 class="usa-alert__heading">Informative status</h4>
        <p class="usa-alert__text">
          Lorem ipsum dolor sit amet,
          <a class="usa-link" href="javascript:void(0);">consectetur adipiscing</a>
          elit, sed do eiusmod.
        </p>
      </div>
    </div>
    
  </div>
</body>
</html>

server.js

const express = require('express');

const app = express();
const port = process.env.PORT || 3000;

// Set folder as root
app.use(express.static('./'));

// Listen for HTTP requests on port 3000
app.listen(port, () => {
  console.log('listening on %d', port);
});

browserSync integration

With #5, I asked a very general question (which was unanswered). Now I am moving to @uswds/compile, and I wonder about something more specific. How can I both utilize the compileSass export and also integrate with browserSync?

I have modified the task "build-sass" from uswds-gulp as follows:

gulp.task("build-sass", function (done) {
  var plugins = [
    // Autoprefix
    autoprefixer({
      cascade: false,
      grid: true,
    }),
    // Minify
    csso({ forceMediaMerge: false }),
  ];
  return (
    gulp
      .src([`${PROJECT_SASS_SRC}/*.scss`])
      .pipe(sourcemaps.init({ largeFile: true }))
      .pipe(
        sass.sync({
          includePaths: [
            `${PROJECT_SASS_SRC}`,
            `${uswds}/scss`,
            `${uswds}/scss/packages`,
          ],
        })
      )
      .pipe(replace(/\buswds @version\b/g, "based on uswds v" + pkg.version))
      .pipe(postcss(plugins))
      .pipe(sourcemaps.write("."))
      // uncomment the next line if necessary for Jekyll to build properly
      //.pipe(gulp.dest(`${SITE_CSS_DEST}`))
      .pipe(gulp.dest(`${CSS_DEST}`))
      .pipe(browserSync.stream())
  );
});

USWDS-Compile - Feature: Set USWDS 3 as the default

Is your feature request related to a problem? Please describe.

Currently USWDS 2 is the default, we should change that to 3 as it's not the main supported version.

Describe the solution you'd like

Update to @uswds/uswds to latest 3.3.0.

Describe alternatives you've considered

No response

Additional context

No response

Code of Conduct

USWDS-Compile - Bug: Source Map is generating a <No Source>

Describe the bug

the output of the styles.css.map shows the following:

... swds-core/src/styles/mixins/typography/typeset.scss","../../../node_modules/%40uswds/uswds/packages/uswds-core/src/styles/mixins/utilities/_margin.scss","../../../node_modules/%40uswds/uswds/packages/uswds-core/src/styles/placeholders/_forms.scss","../../../node_modules/%40uswds/uswds/packages/uswds-core/src/styles/mixins/utilities/_font.scss","../../../node_modules/%40uswds/uswds/packages/uswds-core/src/styles/mixins/utilities/_line-height.scss","<no source>", ...

This no source option is throwing compile warnings for webpack 5

Steps to reproduce the bug

run uswds init
run npm start on a project with webpack 5

Failed to parse source map from '~\src\uswds\css\<no source>' file: Error: ENOENT: no such file or directory, open '~\src\uswds\css\<no source>'

Search for the keywords to learn more about each warning.
To ignore, add // eslint-disable-next-line to the line before.

WARNING in ./src/uswds/css/styles.css (./node_modules/css-loader/dist/cjs.js??ruleSet[1].rules[1].oneOf[5].use[1]!./node_modules/postcss-loader/dist/cjs.js??ruleSet[1].rules[1].oneOf[5].use[2]!./node_modules/source-map-loader/dist/cjs.js!./src/uswds/css/styles.css)
Module Warning (from ./node_modules/source-map-loader/dist/cjs.js):
Failed to parse source map from '~\src\uswds\css\<no source>' file: Error: ENOENT: no such file or directory, open '~\src\uswds\css\<no source>'

If I manually update that no source entry in the list to anything that exists (reuse styles.css again) then the warnings and errors go away.

Expected Behavior

I would expect all css being mapped by the default implementation of the library to have a corresponding source in the map

Related code

No response

Screenshots

No response

System setup

"@uswds/compile": "^1.0.0-beta.3",
"@uswds/uswds": "^3.1.0",

Additional context

No response

Code of Conduct

USWDS-Compile - Bug: Error: spawn EINVAL

Describe the bug

After running USWDS for over yr with good success, Im getting errors all of a sudden. This happens when I either run npx gulp watch or npx gulp compile. Im wondering if anyone encountered these messages and have any suggestions on what I can do to resolve it?

Command prompt is as follows:

C:\inetpub\wwwroot\c360\web\themes\custom\ed_cop>npx gulp compile
[14:38:57] Using gulpfile C:\inetpub\wwwroot\c360\web\themes\custom\ed_cop\gulpfile.js
[14:38:57] Starting 'compile'...
uswds.version: 3
Compiling with USWDS 3.7.0
components\style.scss
Error: spawn EINVAL
[14:38:57] Finished 'compile' after 38 ms

C:\inetpub\wwwroot\c360\web\themes\custom\ed_cop>npx gulp watch
[14:45:00] Using gulpfile C:\inetpub\wwwroot\c360\web\themes\custom\ed_cop\gulpfile.js
[14:45:00] Starting 'watch'...
uswds.version: 3
Compiling with USWDS 3.7.0
components\style.scss
Error: spawn EINVAL

image

/* style.scss */

@use "uswds-core" with (
$theme-image-path: "../assets/img",
$theme-font-path: "../assets/fonts",
$theme-respect-user-font-size: true,
$theme-font-type-sans: "public-sans",
$theme-banner-max-width: "widescreen",
$theme-grid-container-max-width: "widescreen",
$theme-site-margins-breakpoint: "widescreen",
$theme-input-max-width: "desktop",
$theme-font-role-ui: "sans",
$theme-font-role-heading: "sans",
$theme-font-role-body: "sans",
$theme-font-role-code: "mono",
$theme-font-role-alt: "serif",
$theme-type-scale-sm: 5,
$theme-body-font-size: "sm",
$theme-body-line-height: 4,
$theme-color-accent-cool-lighter: #e2f1f3,
$theme-color-accent-cool-light: #b0d9de,
$theme-color-accent-cool: #2b6168,
$theme-color-accent-cool-dark: #0a2231,
$theme-color-accent-cool-darker: #0a2231,
$theme-input-background-color: "white",
$theme-body-background-color: "base-lighter",
$theme-input-tile-border-radius: "lg",
$theme-button-border-radius: "lg"
);
@forward "uswds";

@use "site-wide";
@use "./announcement/announcement";
@use "./sitewide_alert/sitewide_alert";
@use "./resources/resources";
@use "./stepper/stepper";
@use "./quicklinks/quicklinks";
@use "./announcement_deadline/announcement_deadline";

Steps to reproduce the bug

  1. From command prompt 2. From the theme directory where the gulpfile is located 3> Run the command npx gulp watch or npx gulp compile

Expected Behavior

npx gulp compile and watch process without any errors or warnings

Related code

No response

Screenshots

image

System setup

No response

Additional context

No response

Code of Conduct

USWDS-Compile - Feature: Configurable browserslist settings

Is your feature request related to a problem? Please describe.

Customizing the browsers that are supported would allow teams to adjust based on their project needs.

Describe the solution you'd like

Users should be allowed to customize or override browserslist settings with their own configuration.

Describe alternatives you've considered

n/a

Additional context

No response

Code of Conduct

Unable to compile SCSS using Gulp

My team is having trouble with the initial installation of USWDS 3.0 with React 18 and Node 16.10. When running npx gulp init We are dying on the following error though the directory it is claiming is missing is definitely in the correct location;

[16:08:43] Starting 'buildSprite'...
[16:08:43] 'buildSass' errored after 362 ms
[16:08:43] Error: spawn /app/node_modules/sass-embedded/dist/lib/src/vendor/dart-sass-embedded/dart-sass-embedded ENOENT
    at Process.ChildProcess._handle.onexit (node:internal/child_process:282:19)
    at onErrorNT (node:internal/child_process:477:16)
    at processTicksAndRejections (node:internal/process/task_queues:83:21)
[16:08:43] 'init' errored after 13 s

Here is our Gulpfile

const uswds = require("@uswds/compile");

/**
 * USWDS version
 * Set the version of USWDS you're using (2 or 3)
 */

uswds.settings.version = 3;

/**
 * Path settings
 * Set as many as you need
 */

uswds.paths.dist.css = './assets/css';
uswds.paths.dist.sass = './sass';

/**
 * Exports
 * Add as many as you need
 */

exports.init = uswds.init;
exports.compile = uswds.compile;

Our package.json;

{
  "name": "blueprint_ui",
  "version": "0.1.0",
  "private": true,
  "dependencies": {
    "@testing-library/jest-dom": "^5.16.4",
    "@testing-library/react": "^13.1.1",
    "@testing-library/user-event": "^13.5.0",
    "@uswds/uswds": "^3.0.0",
    "gulp-sass": "^5.1.0",
    "husky": "^7.0.4",
    "lint-staged": "^12.4.1",
    "prettier": "^2.6.2",
    "react": "^18.0.0",
    "react-dom": "^18.0.0",
    "react-scripts": "5.0.1",
    "sass-embedded": "^1.50.1",
    "web-vitals": "^2.1.4"
  },
  "lint-staged": {
    "*.{js,jsx}": [
      "eslint",
      "prettier --write"
    ],
    "src/**/*.{ts,tsx,json,css,scss,md}": [
      "prettier --write"
    ]
  },
  "scripts": {
    "start": "react-scripts start",
    "build": "react-scripts build",
    "test": "react-scripts test",
    "eject": "react-scripts eject",
    "prepare": "husky install",
    "pre-commit": "lint-staged"
  },
  "eslintConfig": {
    "extends": [
      "react-app",
      "react-app/jest"
    ]
  },
  "browserslist": {
    "production": [
      ">0.2%",
      "not dead",
      "not op_mini all"
    ],
    "development": [
      "last 1 chrome version",
      "last 1 firefox version",
      "last 1 safari version"
    ]
  },
  "devDependencies": {
    "@uswds/compile": "^1.0.0-beta.2",
    "husky": "^7.0.0"
  }
}

This is a brand new application so there isn't much else going on. Let me know if you'd like more details.

USWDS-Compile - Bug: validate-typeface-token.scss throws a compile error

Describe the bug

When I try to run npx gulp compile, it throws the following error

image

Steps to reproduce the bug

  1. Run npx gulp compile
  2. See error

Expected Behavior

For the SASS to compile successfully

Related code

Gulpfile.js

/* gulpfile.js */

// eslint-disable-next-line import/no-unresolved
const uswds = require('@uswds/compile');

/**
 * USWDS version
 */

uswds.settings.version = 3;

/**
 * Path settings
 * Set as many as you need
 */

uswds.paths.dist.css = './css';
uswds.paths.dist.theme = './sass';

/**
 * Exports
 * Add as many as you need
 */

exports.init = uswds.init;
exports.compile = uswds.compile;

_uswds-theme.scss

@use "uswds-core" with (
    $theme-font-type-icon: true
);

_uswds-theme-custom-styles.scss

@use "uswds-core" as *;

.citations li:not(:last-child)::after {
   content: ";";
}

Screenshots

No response

System setup

  • USWDS version 9.6.4

Additional context

No response

Code of Conduct

USWDS-Compile - Bug: uswds-compile stopped compiling CSS

Describe the bug

In the past week, uswds-compile stopped working. My CSS no longer reflects any changes to my SCSS after I run npx gulp compile. The last-updated date on the CSS file changes, but its contents do not change.

Just now I upgraded from uswds-compile 1.0 to 1.1.0, but this did not resolve the problem.

The uswds-compile package was working without incident for three months prior to this issue.

Steps to reproduce the bug

Run npx gulp compile and inspect the CSS for changes. It does not reflect the changes made in my SCSS file.

Expected Behavior

I expect the CSS to reflect the changes to my SCSS after I compile.

Related code

No response

Screenshots

No response

System setup

"@uswds/compile": "^1.1.0"

"@uswds/uswds": "3.7.0"

The web server is IIS.

Additional context

No response

Code of Conduct

[Test] USWDS-Compile - GitHub issue templates and add-to-project action

Describe the bug

This issue should automatically be added to our project board with tags added.

Steps to reproduce the bug

This issue should automatically be added to our project board with tags added.

Expected Behavior

This issue should automatically be added to our project board with tags added.

Related code

No response

Screenshots

No response

System setup

No response

Additional context

No response

Code of Conduct

Test new label workflow with bug report

Is your feature request related to a problem? Please describe.

a

Describe the solution you'd like

a

Describe alternatives you've considered

No response

Additional context

No response

Code of Conduct

Support nodejs not end of life

Government institutions tend to update their tool suites a little slower than maybe we ought to. I have software I maintain to customize the front-end of https://catalog.nlm.nih.gov/ which will not work with Node 16+, and so I have Node 14 in my path. @uswds/uswds-compile doesn't work with this because "replaceAll" is not a function:

(medmarc) C:\Users\davisda4\Tools>node
Welcome to Node.js v14.18.3.
Type ".help" for more information.

var mystring = "asljdljjasdauo duasi ds groot is as person, groot";
undefined
console.log(mystring)
asljdljjasdauo duasi ds groot is as person, groot
undefined
console.log(mystring.replaceAll("groot", "Groot"))
Uncaught TypeError: mystring.replaceAll is not a function

Compile custom javascript files @uswds3.0

Hello..

Can you please advise how to compile custom javascript files? So far, no issue with compiling scss files.

Lando.yml:

build-sass:
description: Run sass compiler within node service
cmd: cd /app/web/themes/custom/mytheme/ && npx gulp compile
watch-sass:
service: node
description: Run sass compiler within node service
cmd: cd /app/web/themes/custom/mytheme && npx gulp watch

lando watch-sass:

gulpfile.js

/* gulpfile.js */

const uswds = require("@uswds/compile");

/**

  • USWDS version
    */

uswds.settings.version = 3;

/**

  • Path settings
  • Set as many as you need
    */

uswds.paths.dist.css = './files/css';
uswds.paths.dist.theme = './sass'; //custom styles

uswds.paths.dist.js = './assets/js';
uswds.paths.src.js = './js'; //custom scripts
// const copy = {
// js() {
// log(
// colors.blue,
// Copy USWDS compiled JS: ${getSrcFrom("js")} → ${uswds.paths.src.js}
// );
// return src(${getSrcFrom("js")}/**/**.replace("//", "/")).pipe(
// dest(uswds.paths.dist.js)
// );
// },
// };

/**

  • Exports
  • Add as many as you need
    */

exports.init = uswds.init;
exports.compile = uswds.compile;
exports.watch = uswds.watch;
exports.copyJS = uswds.copyJS;

Any help is appreciated

USWDS-Compile - Feature: Update USWDS version & other deps

Is your feature request related to a problem? Please describe.

Update dependencies for 1.1.0 milestone:

  • @uswds/uswds
  • autoprefixer
  • sass-embedded

Describe the solution you'd like

Update USWDS & other dependencies.

Describe alternatives you've considered

No response

Additional context

No response

Code of Conduct

How to update?

Trying to use uswds 3.0 and confused on the proper way to update?

We output the scss files to a directory but if you run init again any changes will be erased

USWDS-Compile - Bug: pnpm support

Describe the bug

Using gulp-compile within a pnpm workspace fails in the buildSass function. pnpm is a package manager that has a local package cache with a unique directory structure.

Steps to reproduce the bug

  1. Use gulpfile.js example from documentation
  2. pnpm gulp build

Expected Behavior

Same as via npx gulp build

Related code

The path resolved here does not exist:

const pkg = require(`../../${uswdsPath}/package.json`).version;

Screenshots

The corresponding exception is:

[14:05:47] 'buildSass' errored after 536 μs
[14:05:47] Error: Cannot find module '../../uswds/package.json'
Require stack:
- /Users/danielnaab/src/10x/atj-platform/node_modules/.pnpm/@[email protected][email protected]/node_modules/@uswds/compile/gulpfile.js
- /Users/danielnaab/src/10x/atj-platform/packages/design/gulpfile.js
- /Users/danielnaab/src/10x/atj-platform/node_modules/.pnpm/[email protected]/node_modules/gulp-cli/lib/shared/require-or-import.js
- /Users/danielnaab/src/10x/atj-platform/node_modules/.pnpm/[email protected]/node_modules/gulp-cli/lib/versioned/^4.0.0/index.js
- /Users/danielnaab/src/10x/atj-platform/node_modules/.pnpm/[email protected]/node_modules/gulp-cli/index.js
- /Users/danielnaab/src/10x/atj-platform/node_modules/.pnpm/[email protected]/node_modules/gulp/bin/gulp.js
    at Module._resolveFilename (node:internal/modules/cjs/loader:1075:15)
    at Module._load (node:internal/modules/cjs/loader:920:27)
    at Module.require (node:internal/modules/cjs/loader:1141:19)
    at require (node:internal/modules/cjs/helpers:110:18)
    at buildSass (/Users/danielnaab/src/10x/atj-platform/node_modules/.pnpm/@[email protected][email protected]/node_modules/@uswds/compile/gulpfile.js:159:15)
    at bound (node:domain:433:15)
    at runBound (node:domain:444:12)
    at asyncRunner (/Users/danielnaab/src/10x/atj-platform/node_modules/.pnpm/[email protected]/node_modules/async-done/index.js:55:18)
    at process.processTicksAndRejections (node:internal/process/task_queues:77:11)
[14:05:47] 'compile' errored after 2.47 ms
 ELIFECYCLE  Command failed with exit code 1.

System setup

  • USWDS Compile version: 1.0.0
  • USWDS version: 3.6.0
  • Device: m1 Macbook Pro
  • Operating system: macOS 13.5.2
  • Browser and version: n/a

Additional context

No response

Code of Conduct

USWDS-Compile - Feature: Support gulp 5

Is your feature request related to a problem? Please describe.

uswds-compile is causing npm audit warnings because it depends on old versions of gulp. Npm audit output follows:

# npm audit report

glob-parent  <5.1.2
Severity: high
glob-parent vulnerable to Regular Expression Denial of Service in enclosure regex - https://github.com/advisories/GHSA-ww39-953v-wcq6
fix available via `npm audit fix --force`
Will install [email protected], which is a breaking change
node_modules/chokidar/node_modules/glob-parent
node_modules/glob-stream/node_modules/glob-parent
  chokidar  1.0.0-rc1 - 2.1.8
  Depends on vulnerable versions of glob-parent
  node_modules/chokidar
    glob-watcher  3.0.0 - 5.0.5
    Depends on vulnerable versions of chokidar
    node_modules/glob-watcher
      gulp  4.0.0 - 4.0.2
      Depends on vulnerable versions of glob-watcher
      Depends on vulnerable versions of vinyl-fs
      node_modules/gulp
  glob-stream  5.3.0 - 6.1.0
  Depends on vulnerable versions of glob-parent
  node_modules/glob-stream
    vinyl-fs  2.4.2 - 3.0.3
    Depends on vulnerable versions of glob-stream
    node_modules/vinyl-fs

postcss  <8.4.31
Severity: moderate
PostCSS line return parsing error - https://github.com/advisories/GHSA-7fh5-64p2-3v2j
No fix available
node_modules/@gulp-sourcemaps/identity-map/node_modules/postcss
  @gulp-sourcemaps/identity-map  >=2.0.0
  Depends on vulnerable versions of postcss
  node_modules/@gulp-sourcemaps/identity-map
    gulp-sourcemaps  >=3.0.0
    Depends on vulnerable versions of @gulp-sourcemaps/identity-map
    node_modules/gulp-sourcemaps
      @uswds/compile  *
      Depends on vulnerable versions of gulp
      Depends on vulnerable versions of gulp-sourcemaps
      node_modules/@uswds/compile

Describe the solution you'd like

Support gulp v5

Describe alternatives you've considered

No response

Additional context

No response

Code of Conduct

USWDS-Compile - Bug: Sourcemaps have incorrect path

Describe the bug

Sourcemaps are compiled correctly and display in the browser inspection tool. However, the directory it points to is incorrect.

For example, the sass files are located at:
/custom/samhsa_data/sass/partial/_home-page2.scss

The sourcemap describes the location as:
/custom/samhsa_data/css/partial/_home-page2.scss

The /css directory is the location for compiled style on this site, there are no sass files anywhere in that directory.

Steps to reproduce the bug

  1. Compile sass using uswds-compile
  2. Using browser dev tool, look at the location of sass files

Expected Behavior

Sourcemap should accurately reflect which directory the sass files come from

Related code

Gulpfile for this project-- nothing special going on outside the defaults

/* gulpfile.js */

const uswds = require("@uswds/compile");

/**
 * USWDS version
 */

uswds.settings.version = 3;

/**
 * Path settings
 * Set as many as you need
 */

 uswds.paths.dist.theme =	"./sass"	// Project destination for theme files (Sass entry point and settings)
 uswds.paths.dist.img =	"./assets/img"	// Project destination for images
 uswds.paths.dist.fonts =	"./assets/fonts"	// Project destination for fonts
 uswds.paths.dist.js =	"./assets/js"	// Project destination for compiled JavaScript
 uswds.paths.dist.css =	"./css"	// Project destination for compiled CSS
 uswds.sprite.projectIconsOnly =	false

 /**
  * Exports
  * Add as many as you need
  */

  exports.compile = uswds.compile;
  exports.watch = uswds.watch;
  exports.init = uswds.init;
  exports.update = uswds.updateUswds;
  exports.default = uswds.watch;

Screenshots

Wrong path displayed in browser dev tool:

Screenshot 2023-06-13 at 12 48 57

System setup

USWDS compile version: 1.0
USWDS version: 3.5
Mac OS (Ventura)
Chrome browser, latest version

Additional context

No response

Code of Conduct

Can't run within lando or any docker container

Attempting to run this in docker generates

[01:01:51] Starting 'default'...
[01:01:51] Starting 'logVersion'...
uswds.version: 2
[01:01:51] Finished 'logVersion' after 1.27 ms
[01:01:51] Starting 'buildSass'...
Compiling with USWDS 2.13.2
[01:01:51] The following tasks did not complete: default, buildSass
[01:01:51] Did you forget to signal async completion?

USWDS-Compile - Feature: show compiled CSS file size

Is your feature request related to a problem? Please describe.

Users should be able to see the total compiled CSS file size when the sass task runs.

Describe the solution you'd like

After successful SASS compilation we should print out the total file size.

Describe alternatives you've considered

n/a

Additional context

Related to uswds/uswds/issues/4781.

Code of Conduct

USWDS-Compile - Feature: Make it easier to find theme settings

Is your feature request related to a problem? Please describe.

As a user I'd like to be able to know which settings I have available to modify without going to the website.

Describe the solution you'd like

Comments with all possible settings.

@use "uswds-core" with (
-  $setting: value,
-  $setting: value,
+  $theme-show-notifications: false,
+ // …Theme settings OR a way to find them without going to website.
);

Describe alternatives you've considered

Pointing them towards settings files in packages directory.

Additional context

A new issue to list of packages would also be nice to have.

Code of Conduct

USWDS-Compile - Feature: Create a pull request template

Is your feature request related to a problem? Please describe.

A PR template would be helpful in creating consistent PR's that have critical information to review.

Things like:

  1. Title format
  2. Release note summary
  3. Linked issue
  4. Problem
  5. Solution
  6. How to test/Testing checklist
  7. Dependency updates

Describe the solution you'd like

A simpler version of USWDS PULL_REQUEST_TEMPLATE.md

Describe alternatives you've considered

n/a

Additional context

No response

Code of Conduct

USWDS-Compile - Feature: Add staying up-to-date with USWDS in usage tips

Is your feature request related to a problem? Please describe.

The README should clearly outline the tasks you need to run to help you stay up-to-date with the latest version of USWDS.

Describe the solution you'd like

A section in usage tips that clarify on how I can stay up-to-date with the latest USWDS release.

https://github.com/uswds/uswds-compile?tab=readme-ov-file#usage-tips

Describe alternatives you've considered

n/a

Additional context

No response

Code of Conduct

Installation fails on linux/arm64

Running npm install @uswds/compile --save-dev as instructed by the documentation fails with the error message

Unexpected platform or architecture: linux/arm64

image

Ignoring all the deprecation warnings, is there a path which works around this failure (skipping the extra bells and whistles this package is trying to pull in) enabling the use of sass to compile the .scss files, or is the only alternative to use the pre-compiled CSS version of USWDS?

USWDS-Compile - Feature: Ability to specify external packages

Is your feature request related to a problem? Please describe.

I have built the beginnings of a USWDS 3 custom design system package. Instead of using USWDS on a single project, and customizing it each time we use it in a new project, this will lay the foundation for us to have consistency across organization projects.

Describe the solution you'd like

To accomplish this, it was necessary to override the buildSass function.

-  return src([`${paths.dist.theme}/*.scss`.replaceAll("//", "/")])
+  return src("src/stylesheets/mywds.scss")
...
-      sass({ includePaths: buildSettings.includes }).on("error", handleError)
+      sass({
+        includePaths: [
+          "./packages",
+          "./node_modules/@uswds/uswds/packages"
+        ],
+        outputStyle: "expanded",
+      }).on("error", handleError)
...
-    .pipe(sourcemaps.write("."))
-    .pipe(dest(paths.dist.css));
+    .pipe(dest("dist/css"))
+    .pipe(postcss(pluginsMinify))
+    .pipe(rename({
+      suffix: ".min",
+    })
+    )
+    .pipe(sourcemaps.write("."))
+    .pipe(dest("dist/css"));

Note:

For my design system package to be able to supply its own theme/ starter files to projects that require it, I had to specify a different source than what is copied from uswds.paths.dist.theme:

So, it seems then that we need:

  1. The ability to optionally specify a compile source that is different from the theme source.
  2. The ability to override the includePaths key of the buildSettings object, and set outputStyle: "expanded".
  3. The ability to optionally specify a different destination than uswds.paths.dist.css.
  4. The un-minified and minified output.

Describe alternatives you've considered

No response

Additional context

With this change, we could document how an organization can build their own USWDS packages to support their entire organization. This also opens up the possibility for community driven packages.

Code of Conduct

paths.src.projectSass not used during complile

When running compile noticed the files in paths.src.projectSass are not called.

Some more background. We are hoping to have init output all of the uswds files (img, fonts, scss, and js) files into an assets folder.

Then in our theme folder we can import the scss file at will without editing it. Which makes updating much easier later. But currently uswds.paths.dist.theme is basically serving 2 purposes and think should be broken up into

uswds.paths.dist.theme
and new path uswds.paths.dist.sass

USWDS-Compile - Bug: gulp vulnerability

Special Note

In digging into this deeper, this appears to be an issue with Gulp, instead of this repo as uswds is on the latest version of gulp and all of the dependency issues reside with gulp 4.0.2. Uswds will need to be upgraded once Gulp fixes its issues

Describe the bug

The issue I am seeing is that USWDS-Compile relies on a version of Gulp that has a transitive dependency with a valid vulnerability:

https://security.snyk.io/package/npm/glob-parent

# npm audit report

glob-parent  <5.1.2
Severity: high
glob-parent before 5.1.2 vulnerable to Regular Expression Denial of Service in enclosure regex - https://github.com/advisories/GHSA-ww39-953v-wcq6
fix available via `npm audit fix --force`
Will install undefined@undefined, which is a breaking change
node_modules/chokidar/node_modules/glob-parent
node_modules/glob-stream/node_modules/glob-parent
  chokidar  1.0.0-rc1 - 2.1.8
  Depends on vulnerable versions of glob-parent
  node_modules/chokidar
    glob-watcher  >=3.0.0
    Depends on vulnerable versions of chokidar
    node_modules/glob-watcher
      gulp  >=4.0.0
      Depends on vulnerable versions of glob-watcher
      node_modules/gulp
        @uswds/compile  *
        Depends on vulnerable versions of gulp
        node_modules/@uswds/compile
  glob-stream  5.3.0 - 6.1.0
  Depends on vulnerable versions of glob-parent
  node_modules/glob-stream
    vinyl-fs  >=2.4.2
    Depends on vulnerable versions of glob-stream
    node_modules/vinyl-fs

7 high severity vulnerabilities
~\web>npm ls glob-parent
~\web
+-- @uswds/[email protected]
| `-- [email protected]
|   +-- [email protected]
|   | `-- [email protected]
|   |   `-- [email protected]
|   `-- [email protected]
|     `-- [email protected]
|       `-- [email protected]

this version of gulp also has a transitive dependency vulnerability for yargs-parser:

Steps to reproduce the bug

run npm install uswds-compile
run npm audit

Expected Behavior

there should be no errors, would it be possible to upgrade the gulp dependency to a version that is not affected by this?

Related code

No response

Screenshots

No response

System setup

No response

Additional context

No response

Code of Conduct

USWDS-Compile - Feature: Flag to stop on errors

Is your feature request related to a problem? Please describe.

With #5334 I ran into an issue with Sass not compiling. I would have expected the Gulp task to fail, but it didn't.

I run the Sass compilation within a CI/CD process but because the gulp task did not error, it allowed the update to pass.

Is there a way emit an error if the Sass compiling, or other tasks, fail?

Not sure if this is a feature request or just a support/documentation request.

Describe the solution you'd like

A way to catch errors in the Gulp tasks so they can be acted upon.

Describe alternatives you've considered

Writing a custom Gulp Sass compiling task, but that adds a maintenance burden that my client may not be comfortable taking on. It also negates one of the main reasons for using this project for our build process.

Additional context

From what I can tell the buildSass task only emits an end event, not an error.

function handleError(error) {
  log(error.message);
  return this.emit("end");
}

Code of Conduct

USWDS-Compile - Bug: "0px and 1 are incompatible"

Describe the bug

When I run npx gulp, I see errors like the following:

Message:
    assets/scss/lib/functions/_strip-units.scss
Error: 0px and 1 are incompatible.
   ╷
16 │   @return (calc($value / ($value * 0 + 1)));
   │                           ^^^^^^^^^^^^^^
   ╵

Steps to reproduce the bug

  1. Run npx gulp
  2. See error:
Message:
    assets/scss/lib/functions/_strip-units.scss
Error: 0px and 1 are incompatible.
   ╷
16 │   @return (calc($value / ($value * 0 + 1)));
   │                           ^^^^^^^^^^^^^^
   ╵

Expected Behavior

I expect it to run without errors.

Related code

No response

Screenshots

No response

System setup

Debian GNU/Linux 11 (bullseye)
NPM 7.5.2

Additional context

I'm not sure what the intent is with this expression: ($value * 0 + 1)

Code of Conduct

USWDS-Compile - Feature: Allow disabling sourcemaps

Is your feature request related to a problem? Please describe.

When using this tool in our USWDS + Drupal + static site generation setup the .map sourcemap files aren't copied over because they are comments in the css and not actual source file references. This causes the .map files to be listed as missing in the console. If we can conditionally disable sourcemaps as an option then we would not have missing files in the console log.

Describe the solution you'd like

Add an option to disable sourcemaps in the output css.

Describe alternatives you've considered

No response

Additional context

No response

Code of Conduct

USWDS-Compile - Feature: Update USWDS and other dependencies

Is your feature request related to a problem? Please describe.

Some dependencies like @uswds/uswds need to be updated.

Describe the solution you'd like

Update packages to non-breaking versions.

Describe alternatives you've considered

No response

Additional context

No response

Code of Conduct

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.