@ebay/skin 18.1.0 → 18.2.1

package/CONTRIBUTING.md

@@ -1,493 +0,0 @@
-# Contributing
-
-This page contains instructions and guidelines for anybody contributing code to the eBay Skin project.
-
-## Table of Contents
-
--   [Contributing](#contributing)
-    -   [Table of Contents](#table-of-contents)
-    -   [System Requirements](#system-requirements)
-    -   [Contribution Steps](#contribution-steps)
-    -   [Development Modes](#development-modes)
-        -   [New Module Creation](#new-module-creation)
-    -   [Versioning](#versioning)
-        -   [API Change](#api-change)
-        -   [New Functionality](#new-functionality)
-        -   [Bug Fix](#bug-fix)
-    -   [Branching](#branching)
-    -   [Package Dependencies](#package-dependencies)
-    -   [Commit Message Format](#commit-message-format)
-    -   [Pull Requests](#pull-requests)
-    -   [Naming Scheme](#naming-scheme)
-    -   [Style Guide](#style-guide)
-    -   [LESS API (deprecated)](#less-api-deprecated)
-    -   [Custom Property API](#custom-property-api)
-        -   [Core Tokens](#core-tokens)
-        -   [Semantic Tokens](#semantic-tokens)
-        -   [Component Tokens](#component-tokens)
-    -   [Dark Mode](#dark-mode)
-    -   [Storybook](#storybook)
-    -   [Visual Regression Testing](#visual-regression-testing)
-        -   [External Contributors](#external-contributors)
-        -   [Internal Contributors](#internal-contributors)
-            -   [Build Modes](#build-modes)
-            -   [Run All Snapshots](#run-all-snapshots)
-            -   [Run Specific Snapshot(s)](#run-specific-snapshots)
-            -   [Technical Notes](#technical-notes)
-    -   [Website](#website)
-    -   [Scripts](#scripts)
-    -   [Icon Creation](#icon-creation)
-    -   [Releases](#releases)
-        -   [Pre-Release](#pre-release)
-        -   [Final Release](#final-release)
-        -   [GitHub Release](#github-release)
-        -   [Hotfix Release](#hotfix-release)
-        -   [Website Archive](#website-archive)
-
-## System Requirements
-
--   [Node.js](https://nodejs.org/en/)
--   [Ruby](https://www.ruby-lang.org/en/)<sup>\*</sup>
--   [Bundler](http://bundler.io)
--   [Jekyll](https://jekyllrb.com) ([install via Bundler](https://help.github.com/articles/setting-up-your-github-pages-site-locally-with-jekyll/#step-2-install-jekyll-using-bundler))
-
-<sup>\*</sup> macOS users may encounter issues with their pre-installed system version of Ruby; in which case we recommend [rbenv](https://github.com/rbenv/rbenv) as a way to manage your Ruby environment.
-
-## Contribution Steps
-
-Before writing any code, please submit a new issue to [GitHub](https://github.com/eBay/skin/issues). Or, if you want to work on an _existing_ issue, please request to do so on the relevant ticket.
-
-We **strongly** advise you to only begin working on issues that are assigned specifically to you and that are part of the upcoming milestone, otherwise your work may end up being in vain.
-
-Here is a rough overview of steps required when contributing code to skin:
-
--   GitHub team members must create a new branch in the Skin repo. Non-team members should create their own fork.
--   Please ensure you branch off from the correct milestone branch! See branching strategy section below.
--   Skin adopts the [BEM](https://css-tricks.com/bem-101/) methodology (a popular naming convention for classes in HTML and CSS). Please familiarize yourself with our style guide in the section below.
--   After making changes to `.less` files, ensure that no new CSS lint warnings or errors are introduced
--   Add or update the corresponding website documentation. More information in the [documentation](#documentation) section below.
--   Push commit(s) to the upstream branch. Ensure new dist files (i.e. the compiled CSS files) are included!
--   Send pull request. See Pull Requests section below.
-
-## Development Modes
-
-Skin can usually considered to be in one of two modes of development:
-
-1. Feature development mode (default)
-1. Refactoring/cleanup/breaking-changes mode
-
-The vast majority of this guide is relevant to both modes.
-
-### New Module Creation
-
-Executing the following script will generate all files and references for a new module:
-
-```
-./scripts/develop-module -m "Your Module Name"
-```
-
-_Example_
-
-```
-./scripts/develop-module -m toast-dialog
-```
-
-Add applicable metadata about the component to the `module_metadata` map in [docs/index.html](https://github.com/eBay/skin/blob/master/docs/index.html):
-
-```yaml
-your-module-name: # the Skin module name
-    ds-component: # module's relationship with the eBay Design System
-        name: # eBay Design System component name
-        version: # version of the eBay Design System component implemented in Skin
-    status: # status, e.g. "beta", "deprecated", "in-progress"
-    submodules: # array of Skin modules used in this module
-```
-
-If the Skin component is used for multiple Design System components, include those as an array in the `ds-component` field. For example:
-
-```yaml
-lightbox-dialog:
-    ds-component:
-        - name: modal
-          version: 2.1
-        - name: bottom-sheet
-          version: 2.1
-    submodules:
-        - button
-        - icon-button
-```
-
-When updating a Skin module to match an updated Design System design, make sure to update its version in its `ds-component` field.
-
-## Versioning
-
-Skin follows [Semantic Versioning](http://semver.org):
-
-1. MAJOR version when we make incompatible API changes,
-1. MINOR version when we add functionality in a backwards-compatible manner
-1. PATCH version when we make backwards-compatible bug fixes.
-
-To help guide your contribution into the right bucket, we provide more detailed insight into each type of change in the sections below.
-
-### API Change
-
-Here are some types of change that we consider as an incompatible API change:
-
--   Removal of a CSS class
--   Removal of a public variable or mixin
--   Removal of a `browser.json` file
--   Removal of a folder from `dist`
--   Removal of an SVG icon
--   Change to CDN path structure
--   Change to HTML structure or attributes of module
--   Change to CSS property that radically alters appearance and/or layout
-
-Typically we will try and add a deprecation note for a period of time before introducing any breaking API change. The creation of aliases can often help ease the transition from one API to another.
-
-### New Functionality
-
-Here are some of the changes we consider as new functionality:
-
--   Addition of a new module
--   Addition of a module subtype or variant
--   Addition of a new variable or mixin
--   Addition of an alias for a class or icon
--   Update of a module to its latest playbook version
--   Update of a colour value that remains within the same hue
--   Update of a CSS property that does not affect the modules layout in page
-
-Minor version updates are a signal that there is something new (no matter how small) that an app might be interested in using!
-
-### Bug Fix
-
-Bug fixes can perhaps best be summed up as: "fixing something that does not work as expected or documented".
-
-**NOTE:** Updating a module to its latest visual specification is NOT a candidate for a bug fix. No matter how small or trivial the visual update may be, we always consider it as new functionality.
-
-## Branching
-
-Do not attempt to commit feature work directly to the `master` branch. Pushes to the `master` branch are restricted to admins and should only be used for important corrections to the documentation or website.
-
-All other branches are "milestone" branches or "issue" branches.
-
-Work for every "issue" must go in its own branch. The branch name will reflect the issue number and issue type. For example, for an issue number 202, related to the pagination module, a branch named `202-pagination` would be created.
-
-Issue branches must be created from the relevant milestone branch. For example, if issue 202 will go out in the v2.6.7 milestone, then the 202 issue branch must be created from the 2.6.7 milestone branch.
-
-Every milestone branch must be created from the `master` branch. For example, when beginning work on the 2.9.0 release, the `2.9.0` branch would be created from the `master` branch.
-
-When all milestone issues are complete, and merged into the milestone branch, a Skin admin will merge the milestone branch into the `master` branch in preparation for the release.
-
-A milestone branch will be deleted after it has been merged into `master`. There is no need to keep these milestone branches lying around, as we can go back to any point in time using tags. See the hotfix section below for more details.
-
-## Package Dependencies
-
-Every time we cut a new milestone branch, the package dependencies require updating.
-
-1. Ensure you are on the milestone branch and that the branch is up to date with latest from `master`
-1. Run `npm install` to ensure your local node_modules are in sync with your `package-lock.json`
-1. Run `npm outdated`
-1. Go into `package.json` and update version numbers to the latest based on outdated. Pay attention to any major version updates as they may contain breaking changes!
-1. Run `npm install` again. This will update `package-lock.json`.
-1. Run `npm run build`, `npm start` and `npm run storybook` and make sure those commands execute correctly
-1. Check in `package.json` and `package-lock.json` as `chore: updated dev deps`.
-
-## Commit Message Format
-
-We use [commitlint conventional configuration](https://github.com/conventional-changelog/commitlint/tree/master/@commitlint/config-conventional) to lint all commit messages.
-
-When determining the commitlint type, use the following guidance:
-
-build
-: package scripts or build scripts
-
-ci
-: GitHub Actions
-
-chore
-: project file/folder structure
-
-docs
-: website docs/examples
-
-feat
-: new Skin module
-
-fix
-: bug fix on a Skin module
-
-refactor
-: refactor of a Skin module
-
-revert
-: revert previous commit
-
-style
-: website or storybook styles
-
-test
-: storybook stories
-
-## Pull Requests
-
-Guidance for pull requests:
-
--   Always double-check which branch you are attempting to merge into. The target branch should always be a milestone branch!
--   Only Skin admins are permitted to merge into `master`
--   Non-atomic commits should be squashed (i.e. "work in progress" type commits).
--   Do not add any commit that leaves the code in a broken state.
--   Pull request for a _feature_ must only contain changes related to the issue (NOTE: refactoring/cleanup type PRs are often exempt from this rule)
--   **Do not** be tempted to go fixing or refactoring unrelated issues. Doing so can make the code reviewer's job more difficult and/or time consuming, as well as increasing risk of regression
--   If you spot some other unrelated bug or code smell, please create a GitHub issue for it.
--   After the pull request has been merged, your issue branch should be immediately deleted (by yourself or admin)
-
-## Naming Scheme
-
-eBay Skin is an implementation of the [eBay MIND Patterns](https://ebay.gitbook.io/mindpatterns). The MIND patterns [naming scheme](https://ebay.gitbook.io/mindpatterns/appendix/pattern-naming-scheme) follows an accessibility-first mindset; thus aligning our developer speak as closely as possible with existing W3C web standards & conventions.
-
-## Style Guide
-
-When contributing to Skin, please bear the following guidelines in mind:
-
--   Ensure all markup adheres to our [accessibility patterns](https://ebay.gitbooks.io/mindpatterns/content/)
--   Ensure all markup is valid HTML
--   Leverage ARIA roles, states and properties for styling hooks wherever possible. This safeguards against non-accessible markup (NOTE: this will increase specificity, but we accept this as a worthwile tradeoff)
--   Use BEM syntax for modifiers (double-dash) and nested classes (double-underscore)
--   Use the `<svg>` tag for icons
--   Never use the `<i>` tag for icons
--   Harness CSS margin-collapse wherever possible.
--   Most block-level modules will require margin top and bottom as a sensible default
--   Do not use presentational classnames, e.g. `.btn--green` should be `.btn--secondary` for example
--   Do not combine classes into a single classname, e.g. `btn-sec` should be `btn btn--sec`, this allows cascades without advanced attribute selectors or pre-processors
--   Do not chain BEM modifiers (e.g. `.btn--large.btn--primary`). This is a code smell.
--   Do not use ambiguous or global classnames, e.g. `.large` should be `.btn--large`
--   Do not use class `.disabled` to disable buttons or form elements, use the HTML `disabled` property instead
--   Do not wrap inputs with labels, use explicit labels instead (e.g. use the `for` and `id` attributes)
--   Do not use `href="#"` or `href="javascript"` in examples, use `href="http://www.ebay.com"` or any other dummy url
--   Every `<img>` tag must have an `alt` attribute, with **no** exceptions. The value can be an empty string for presentational images.
--   Avoid naming conflicts with other grid systems (e.g. Bootstap Grids)
--   Keep LESS pre-processor usage restricted to variables, mixins and basic nesting (see below). 9 times out of 10 advanced features of pre-processors can be avoided by using CSS properly.
--   Avoid too much nesting/indenting of LESS selectors as it can reduce human scan-ability of code and can also result in sub-optimal compiled CSS. Try and restrict nesting to pseudo selectors only (e.g. `:focus`, `::after`).
--   Avoid over specificity (unless required for accessibility safeguarding). The fewer rules required to check for a given element, the faster style resolution will be. This is the key to dramatically increasing performance.
-    [https://developer.mozilla.org/en-US/docs/Web/Guide/CSS/Writing_efficient_CSS](https://developer.mozilla.org/en-US/docs/Web/Guide/CSS/Writing_efficient_CSS)
--   Please do not commit commented out code to production.
-
-## LESS API (deprecated)
-
-In comparison to past versions, Skin now offers a very minimal public LESS API (i.e. variables and mixins). Over time this may be reduced to zero. This is mainly due to the introduction of CSS Custom Properties (see next section below).
-
-## Custom Property API
-
-Skin has a token based system that leverages CSS Custom Properties. The tokens are categorised into three levels:
-
--   core
--   semantic
--   component
-
-Skin provides a set of core and semantic defaults but, in order for modules to render correctly, they **must be explicitly included** by the end user.
-
-### Core Tokens
-
-Core tokens are our primitives. They currently represent colour and border radius, but in time will go on to include spacing, type ramp, breakpoints and more. For example:
-
--   color-neutral-1
--   color-blue-4
--   border-radius-100
--   spacing-100 (not yet available)
-
-### Semantic Tokens
-
-Semantic tokens are aliases of core tokens. They represent an aspect of the interface that is common across the site. For example:
-
--   color-background-primary
--   color-background-confirmation
--   color-foreground-on-confirmation
-
-**NOTE**: semantic token values may change dynamically at runtime depending on the "prefers-color-scheme" media query (i.e. [Dark Mode](#dark-mode)).
-
-### Component Tokens
-
-Component tokens are not used by Skin itself, but we expose them as a "brute-force" means for a page to override the system described above for one specific aspect of a component. For example:
-
--   badge-background-color
--   switch-checked-background-color
--   textbox-placeholder-color
-
-Obviously with great power, comes great responsibility.
-
-## Dark Mode
-
-Every Skin module has full support for [dark mode](https://developer.mozilla.org/en-US/docs/Web/CSS/@media/prefers-color-scheme).
-
-Dark mode is powered by the [Custom Property API](#custom-property-api). When the "prefers-color-scheme" media query is satisfied, all semantic token values will be replaced, dynamically at runtime, with the values from the relevant tokens module (e.g. `evo-semantic-dark` or `evo-semantic-light`).
-
-**NOTE:** the semantic dark mode tokens are **not** included by default. They must be explicitly bundled by the end user. This allows end users to opt-in to dark mode only when their base page is ready for it.
-
-## Storybook
-
-Every module requires a page in storybook. In addition to the main use cases, try and cover as many variants, scenarios and edge cases as possible. The following tests are required for every module:
-
--   RTL (right to left languages)
--   Font-Size increase (up to 200%)
--   Color inheritance (to a certain degree)
-
-Each story must be isolated to a single test. This allows us to easily run visual regression testing.
-
-## Visual Regression Testing
-
-We use Percy to do visual regression and compare visual changes in feature branches with the UIs in production. As such, changes to any specific module will need to verified against unintended consequences of those changes. This is usually to be done by internal contributors.
-
-### External Contributors
-
-External contributors cannot run Percy visual regression tests. However, they should mark the modules that were changed in pull requests to allow the internal team to run visual regression tests.
-
-### Internal Contributors
-
-Internal contributors will need to set up to run Percy snapshots by adding the Percy token to their operating system's environment variables. On a Mac, it would be like so:
-
-`export PERCY_TOKEN=[TOKEN_GOES_HERE]`
-
-This will allow internal contributors to run Percy snapshot tests.
-
-Snapshots will likely be ran by developers locally before pushing up changes. Once they are ran, Percy dashboard should be checked to ensure no unintended style changes have taken place. If there are unintended style changes that have occurred, those should be reverted/fixed. Once the set of new local changes is final and in scope with the changes related to the issue, the snapshot run will need to be marked as the canonical version against which future updates are compared.
-
-#### Build Modes
-
-Running snapshots has two modes for all variations - build mode and dry mode.
-
-Build mode creates snapshots for stories, uploads the snapshots to Percy and created a new Percy build for the purposes of making comparisons to previous visual builds.
-
-Dry mode runs through snapshots (mainly for the purpose of verifying which stories will be captured) but does not upload the snapshots and does not create a Percy build.
-
-#### Run All Snapshots
-
-To run all storybook snapshots in build mode:
-`npm run snapshots:all`
-
-To run all storybook snapshots in dry mode:
-`npm run snapshots:all:dry`
-
-#### Run Specific Snapshot(s)
-
-To run single specific storybook snapshot in build mode for single module:
-`npm run snapshots 'Button'`
-
-To run multiple specific storybook snapshots in build mode for single module:
-`npm run snapshots 'Button,Icon'`
-
-To run single storybook snapshots in build mode for single module:
-`npm run snapshots:dry 'Button'`
-
-To run multiple storybook snapshots in dry mode for single module:
-`npm run snapshots:dry 'Button,Icon'`
-
-#### Technical Notes
-
-As internal contributors may see in `package.json`, there are two other scripts, `snapshots:execute`, `snapshots:execute:dry`. These are scripts that should not be run directly. They are fired from `gulpfils.js` after the Percy storybook regexes have been formatted.
-
-## Website
-
-First, be sure to Run `npm install` to install all dependencies from NPM.
-
-We use [Jekyll](http://jekyllrb.com) to generate HTML from templates, [LESS](https://lesscss.org) to preprocess and compile CSS, and [Babel](https://babeljs.io/) with [Webpack](https://webpack.js.org/) to compile and bundle JS. The website can be run and hosted locally (see next section) during development.
-
-We use [Bundler](http://bundler.io) to install, update and run Jekyll in our dev environment. This ensures the same Jekyll environment as GitHub Pages. GitHub have created a nice guide called [Setting up your GitHub Pages site locally with Jekyll](https://help.github.com/articles/setting-up-your-github-pages-site-locally-with-jekyll/) which we recommend you follow.
-
-Once Jekyll is setup successfully, running a build should create the following file structure under `./_site`:
-
--   `./_site/static/common/docs.min.js`
-    -   this is the Babel & Webpack output of `./docs/src/js/main.js`
--   `./_site/static/dsx/docs.min.css`
-    -   this is the SASS compiler output of `./docs/src/sass/dsx.less`
--   `./_site/static/dsx/skin.min.css`
-    -   the full, minified skin css bundle (only used in development environment)
--   `./_site/index.html`
-    -   homepage
--   `./_site/archive`
-    -   archive of old versions of website
-
-This is the exact same structure that will be generated by GitHub Pages.
-
-Our GitHub Pages source is located in the `docs` folder.
-
-In order to start developing the website simply run: `npm start` which will build, bundle and run a BrowserSync server at http://localhost:3000.
-
-## Scripts
-
-The following scripts are available via npm:
-
--   `npm start` - Runs a build and starts local BrowserSync server on port 3000
--   `npm test` - Runs a build and lints CSS and LESS files
--   `npm run build` - Runs a build only (no server)
-
-## Icon Creation
-
-To add new SVG icons, please follow the [icon creation guide](ICON-CREATION.md).
-
-## Releases
-
-The `@ebay/skin` module is published to the public NPM repository at https://registry.npmjs.org/.
-
-Please ensure your NPM registry is set correctly and that you are on the package owners list, i.e. `npm owner ls @ebay/skin`.
-
-### Pre-Release
-
-A pre-release is always made from a milestone branch.
-
-1. Run `npm version prepatch`, `npm version preminor`, or `npm version premajor`. If you need to increment an existing prerelease use `npm version prerelease`. This command will automatically:
-    - update the version number in css build files
-    - update the version number in `package.json`
-    - commit all changes locally
-    - create a Git tag
-1. Push commit to origin.
-1. Run `npm publish --tag beta` to publish the package to NPM.
-
-### Final Release
-
-A final release is always made from the master branch.
-
-1. Create a GitHub PR to merge the milestone branch into master branch.
-1. Merge the PR after approval (do not squash!)
-1. Switch to your local master branch and pull the changes from origin.
-1. Run `npm version patch`, `npm version minor`, or `npm version major`. This command will automatically:
-    - update the version number in css build files
-    - update the version number in `package.json`
-    - update the version number in Jekyll docs
-    - commit all changes locally
-    - create a Git tag
-1. Push commit to origin.
-1. Push the git tag to origin, e.g. `git push origin v3.1.0`.
-1. Run `npm publish` to publish the package to NPM.
-1. Publish the `/_cdn/skin/{version}` folder to the CDN.
-
-### GitHub Release
-
-After the module has been successfully pushed to NPM you should go ahead and create a [Git release](https://github.com/eBay/skin/releases) using the new Git tag that was created.
-
-The release notes should reference all issues inside the relevant milestone.
-
-### Hotfix Release
-
-If the `master` branch is currently at `v12.x`, but we need to go back and apply a critical bug fix to `v6.3.x`, what do we do?
-
-Git tags to the rescue! Git tags allow us to go back to any moment in time that we have previously "tagged".
-
-**Do not try and push an entire feature in a hot fix!! A hotfix is allowed for small one-liner type fixes only.**
-
-1. Go to tags page: https://github.com/eBay/skin/tags
-1. Select the tag you'd like to go back in time to, e.g. https://github.com/eBay/skin/tree/v6.3.5
-1. Select the tag dropdown and create a new branch named accordingly, e.g `6.3.6`. This is the branch you will merge your PR to and do the release from.
-1. Create _another_ branch for your local dev work, e.g. `1723-textbox-fix`.
-1. Now follow the [release steps](#final-release) mentioned above, but substituting `master` branch for your release branch (e.g. `6.3.6`) and milestone branch for your dev branch (e.g. `1723-textbox-fix`). **IMPORTANT:** No changes should be pushed to master branch!
-1. Don't forget to publish your new git tag (e.g. `v6.3.6`)
-1. Use `npm publish --tag hotfix` when publishing to NPM to tag this as a hotfix.
-
-### Website Archive
-
-The website archive under `/docs/archive` should be updated each time a minor or major release is published.
-
-1. In a local branch, checkout the tag of the previous version, e.g. `git checkout v10.7.5`
-1. Run `yarn`
-1. Run `yarn build`
-1. Copy relevant generated files only from `/_site` to a subfolder of `/docs/archive`
-1. Create a pull request

package/ICON-CREATION.md

@@ -1,51 +0,0 @@
-# Icon Creation
-
-Skin uses the SVG tag to deliver all iconography. This guide will help you properly add or modify SVG files for the Skin library.
-
-**Base Icons Only**
-
-Only base icons should be used. No state-based icons, such as disabled icons or even possibly an icon relaying an error state (likely red), should be used. Those state modifications on icons should be handled downstream using `css` modifiers to allow for those variations.
-
-## Step 1: Import the SVG
-
-In order to import the SVG into Skin, all you need to do is drop the SVG into `src/svg/icon` directory. The icon name will be the way the icon will be imported into Skin. If the icon does not have `icon-` prefix, it will be renamed automatically to include the prefix.
-The viewbox given will be translated to the `width` and `height` that the icons is going to use.
-
-**Couple of Notes**
-
--   We should not apply fill on base icons. We use `fill: currentColor` to be able to change the color on icons
--   We should not apply base sizes. We will apply those using CSS
--   If there is a `<use>` tag, move necessary attributes to the `<path>` and remove this tag
-    -   Specific attributes to look for: `fill` (if it needs to be different), `fill-rule`, etc.
--   In all cases, remove the `id` from the `<path>`, as it is unnecessary
--   If `id` is needed for certain `clip-path` or such, make sure it is unique
-
-## Step 2: Run scripts
-
-To properly setup the icon after it is placed in the `src/svg/icon` directory, run `node scripts genSVG` from the root of the skin project. This will properly setup the icon in docs, in the `icon.svg` bundle, and generate the CSS needed for the icon.
-Afterward, you should run `npm run build` in order to also copy all those files to `dist`.
-
-## Appendix
-
-## Star-rating
-
-Star rating icons are the only unique set of icons. These will not recieve an `icon-` prefix
-
-## Skip skin docs
-
-If you do not want an icon to show up in the skin docs, add the name of the icon in `docs/_data/icons.yaml` under `skipDocs` key. Then rerun `step 2` scripts.
-
-## Skip CSS generation
-
-In order to skip an icon to have it's CSS be generated add the name of the icon in `docs/_data/icons.yaml` under `skip` key. Then rerun `step 2` scripts.
-This can be done for certain icons which might want to have different sizes than those specified in the `viewbox`
-
-## Deprecating Icons
-
-When an icon is removed or renamed, it will need to get deprecated. If you want to deprecate an icon, add the name of the icon in `docs/_data/icons.yaml` under `deprecated` key. Then rerun `step 2` scripts. This will show (if none existed yet) a `Deprecated` section in the docs and include the icon. This will also remove the icon from the `icon.svg` bundle and remove the CSS for the icon.
-
-Deprecated icons are to remain until the next major version when they can be removed. After they are removed, the icon can be removed from the `deprecated` key and the `step 2` scripts can be rerun.
-
-## Script changes
-
-Any script changes needed should be done in `scripts/generate-images.js`.

package/lint.log

@@ -1,10 +0,0 @@
-
-/home/runner/work/skin/skin/docs/src/js/main.js
-    1:1   warning  Unused eslint-disable directive (no problems were reported from 'no-console')
-   41:56  warning  Unused eslint-disable directive (no problems were reported from 'no-console')
-  287:25  warning  Unused eslint-disable directive (no problems were reported from 'eqeqeq')
-  289:25  warning  Unused eslint-disable directive (no problems were reported from 'eqeqeq')
-
-✖ 4 problems (0 errors, 4 warnings)
-  0 errors and 4 warnings potentially fixable with the `--fix` option.
-

package/scripts/README.md

@@ -1,77 +0,0 @@
-# Ebay Skin Scripts
-
--   [Ebay Skin Scripts](#ebay-skin-scripts)
-    -   [cdn-bundle.js](#cdn-bundlejs)
-    -   [scripts runner](#scripts-runner)
-    -   [bundle](#bundle)
-        -   [Examples](#examples)
-    -   [gen](#gen)
-    -   [clean](#clean)
-    -   [genSVG](#gensvg)
-        -   [Configuration](#configuration)
-    -   [importSVG](#importsvg)
-        -   [Usage](#usage)
-
-## cdn-bundle.js
-
-This script automatically updates the CDN version inside of the HTML based on the version specified in `package.json`.
-
-## scripts runner
-
-Run `node scripts` to execute the runner. This will give you info about each command.
-
-## bundle
-
-This script allows users to create their own custom Skin bundle.
-In order to view all the avaialbe options and subcommands you can run `scripts bundle --help`. Also eash subcommand has it's own help.
-
-### Examples
-
-| Command                                         | Description                                                                    |
-| ----------------------------------------------- | ------------------------------------------------------------------------------ |
-| `scripts list`                                  | Lists the available modules for use with the `--modules` option                |
-| `scripts bundle ebay --modules global carousel` | Creates a bundle called ebay which consists of the global and carousel modules |
-| `scripts bundle ebay --scope-class ebay-wrap`   | Creates a bundle called ebay which has all styles wrapped by `.ebay-wrap`      |
-
-## gen
-
-Generates top level imports. See `generate-imports/README.md`
-This creates multiple files. We create a `{module}.browser.json` a `{module}.js` a `{module}.css` and a `{module}.mjs` file, where the module is each skin module.
-These are easy improts to all dist files, which include all of each of the modules dependencies.
-A js file is included as a way to import in any bundler (`lasso`, `wepack`, or `vite`). This allows a common way for bundlers to import the modules and not duplicate any imports. However, CSS and MJS files are also available if needed for different bundlers or imports directly form less files or module imports.
-
-## clean
-
-Cleans top level improts. See `generate-imports/README.md`
-
-## genSVG
-
-Generates less files with width/height styles for all icons located in `src/svg` directory. See the `configuration` section for more info on how to configure.
-
-### Configuration
-
-Configuration for this script is located at `docs/_data/icons.yaml`
-This contains a list of icon modules to generate. Each key will look up an icon file, if that exists then it will generate css for those.
-
-| Global Config | Description |
-| `skip` | The id of icons to not generate config for |
-
-| Icon specific config | Description                                                                                                                                    |
-| -------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------- |
-| `prefix`             | The prefixed name, this will be used as the beginning part of the icon name as well as the default output directory if `output` is not defined |
-| `size`               | Default size for these icons. Defaults to 24px for regular sizes, and 16px for small.                                                          |
-| `postfix`            | The postfix name, this will be used as the end part of the icon name                                                                           |
-| `file`               | The `src/svg` filename to pull icons from                                                                                                      |
-| `output`             | The file directory to output the generated css file to. Defaults to the `src/sass/icon` directory.                                             |
-
-## importSVG
-
-Script used to import an SVG into the icon file. It will try to optimize the SVG and remove any unused tags.
-It is recommended to run `scripts gen` script after running the `scripts importSVG` script
-
-### Usage
-
-`scripts importSVG path/to/svg.svg svgID skinSvgFileName`
-
-_Example_
-`scripts importSVG ~/Downloads/newSvg.svg icon-new-large-icon large`

package/scripts/add-y-comments.js

@@ -1,33 +0,0 @@
-// This is a hack added in order to allow the carousel to work in older parsers
-const fs = require("fs");
-const path = require("path");
-const currentDir = path.dirname(__dirname);
-const carousel = path.resolve(currentDir, "dist", "carousel");
-const carouselCSS = path.resolve(carousel, `carousel.css`);
-fs.readFile(carouselCSS, "utf8", function (err, data) {
-    if (err) {
-        return console.log(err);
-    }
-    const result = data
-        .replace(
-            /\@supports not (.|\n)+?\{/,
-            `@supports not /*!Y */
-      (
-            /*!Y */ (-webkit-scroll-snap-coordinate: 0 0) or /*!Y */
-            (-ms-scroll-snap-coordinate: 0 0) or /*!Y */
-            (scroll-snap-coordinate: 0 0) or /*!Y */ (scroll-snap-align: start)
-      ) {`,
-        )
-        .replace(
-            /\@supports \((.|\n)+?\{/,
-            `@supports (
-    /*!Y */ (-webkit-scroll-snap-coordinate: 0 0) or /*!Y */
-        (-ms-scroll-snap-coordinate: 0 0) or /*!Y */
-        (scroll-snap-coordinate: 0 0) or /*!Y */ (scroll-snap-align: start)
-) {`,
-        );
-
-    fs.writeFile(carouselCSS, result, "utf8", function (err) {
-        if (err) return console.log(err);
-    });
-});

package/scripts/develop-module

@@ -1,4 +0,0 @@
-#!/usr/bin/env node
-const developModule = require('./develop-module_proper');
-
-developModule();