@jamesodwyer/gds-figma-vite 1.0.3 → 1.0.5

package/README.md

@@ -1,12 +1,16 @@
 # Global Design System Component Library
 
-View the latest build of the GDS documentation site at: <http://global-design-system.git.tmaws.io/gds>
+A shared React component library built with styled-components.
+
+## NPM
+
+https://www.npmjs.com/package/@jamesodwyer/gds-figma-vite
 
 ## Contributing
 
 ### Icons
 
-View the instructions on adding new icons at: <http://global-design-system.git.tmaws.io/gds/?path=/docs/icons--docs#adding-new-themeable-icons>
+View the instructions on adding new icons in the Storybook documentation.
 
 ## Storybook
 

package/docs/__stories__/introduction.mdx

@@ -8,7 +8,7 @@ Global Design System (GDS) is a shareable pattern library. It exposes both core
 
 Formerly known as Mosaic, GDS is based on pure JS objects for the core variables, React for the components, Styled Components for the UI library (as the most widely adopted) and polished for some of the color interpolations (optional). All elements in GDS are built in a way so they can be imported individually without the need to import the whole library. They are also built with emphasis on flexibility and accessibility.
 
-It is currently being used in several Ticketmaster projects including [ICCP Frontend](https://git.tmaws.io/intl-ccp/iccp), the [Microflex mobile app](https://git.tmaws.io/intl-ccp/mobile/iccp-app), and the [Resale checkout](https://git.tmaws.io/intl-resale/checkout/checkout-app).
+It provides reusable UI components, icons, stickers, and theming utilities for React applications.
 
 This Storybook is a helpful resource with a guide to every component we have as well as all the spacing values, colours and icons we have access to. You can play around with the controls in each canvas to see the different variants of the component.
 If you click the Docs link in the top left corner, you can see some documentation with extra notes on how you can (and can’t) configure/use a component.
@@ -84,6 +84,5 @@ When opening a merge request, please remember to fill out the template fully. Yo
 
 ## Links
 
-- Slack channel: [#global-design-system](https://ticketmaster.slack.com/archives/C8SM3AUKE)
-- Repo: https://git.tmaws.io/global-design-system/gds
-- Jira project: https://jira.livenation.com/projects/GDS/issues
+- Repo: https://github.com/jamesodwyer/gds-figma-vite
+- NPM: https://www.npmjs.com/package/@jamesodwyer/gds-figma-vite

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@jamesodwyer/gds-figma-vite",
-  "version": "1.0.3",
+  "version": "1.0.5",
   "publishConfig": {
     "access": "public"
   },
@@ -57,7 +57,7 @@
   "prettier": {},
   "repository": {
     "type": "git",
-    "url": "https://git.tmaws.io/global-design-system/gds"
+    "url": "https://github.com/jamesodwyer/gds-figma-vite"
   },
   "author": "TMFE",
   "license": "UNLICENSED",

package/docs/__stories__/releasing.mdx

@@ -1,155 +0,0 @@
-import { Meta } from "@storybook/addon-docs/blocks";
-
-<Meta title="Docs/Releasing" />
-
-# Releasing GDS
-
-Once you have the code review approved, you merge to master and let the pipeline run.
-When it's all green you create a tag in GitLab in the same way as you do in your repo.
-A release of `GDS` is performed by adding a Git tag to the `master` branch. Tagging master will trigger a CI pipeline which will build and release the new version of the package to npm.
-
-## How to prepare a tag
-
-You'll need to build some release notes for the tag, so this preparation step gives you one way to do that. There are multiple approaches, but this one is quite user-friendly.
-
-### 1. Make sure the master pipeline is passing on CI
-
-Check that the [latest master pipeline](https://git.tmaws.io/global-design-system/gds/-/pipelines?page=1&scope=all&ref=master) passed on CI (has a green tick)
-
-Check your pipeline that ran as part of your MR to ensure each step passed
-
-### 2. Build the release notes
-
-Run the following gds repo script in the terminal:
-
-```bash
-./scripts/merges-since-last-tag.sh
-```
-
-This will helpfully print a list of all the commits to master since the previous tag.
-
-Post this list in the [#global-design-system](https://livenation.enterprise.slack.com/archives/C8SM3AUKE) Slack channel to let people know a tag is incoming. If no objections have been raised within ~10 minutes, proceed with the tag.
-
-### 3. Go back to "[Deployments > Releases](https://git.tmaws.io/global-design-system/gds/-/releases)" in GitLab and click "New release"
-
-- Give the tag a name (its release number) following the semantic versioning pattern (`major.minor.patch`). Most "daily" releases are generally classed as minor.
-  Enter this new version number in the "Search or create tag name" field. Under the autocomplete list, it will prompt you to "Create tag [version]"
-- Make sure the tag is created from `master` and paste the release notes into the tag message field
-- Leave the Release title, Milestones and Release date fields as they are
-- Paste the same release notes into the "Release notes" field. This is a markdown field, so we can format it as a list for easy readability
-- Remove any duplicates and make sure the Jira numbers are correctly formatted (case sensitive) - this will help you in a bit!
-- Note: doing this will highlight the importance of good/standard commit messages!
-- Click "Create release". This will trigger a pipeline that builds and release the new version of the package to npm.
-  - [GDS pipeline here](https://git.tmaws.io/global-design-system/gds/-/pipelines)
-
-### 4. Once the [deploy](https://git.tmaws.io/global-design-system/gds/-/pipelines) has been successful, update the Jira issues to reflect their "done" status
-
-You'll notice that each Jira issue ID is a hyperlink in your release notes. You should open all of these in new tabs.
-For each Jira issue, click "Workflow > Done" to resolve the issue. Set the "resolution" to "completed" and in the comment, add something along the lines of "Deployed in gds release: [link to the release on GitLab]".
-Don't resolve any Jira issues until you're sure the deploy was successful. "Done" means tagged, not merged.
-You're done! Now you can get back to work!
-
-## How to import GDS changes into your repo
-
-Once the tag is created, the pipeline will run which includes the step to publish to npm. After that, you can use the tag number just created to bump the version in your repo's `package.json`, subsequently run:
-
-`npm update <packagename>`
-
-So, in our case:
-
-```bash
-npm update @ticketmaster/global-design-system
-```
-
-Now you should have access to the changes and can make a MR for your repo.
-
----
-
-## Releasing a hotfix
-
-This guide is for you if you want to cherrypick some commits instead of releasing everything inside the master branch.
-
-### 1. Checkout the latest tag you want to branch off from
-
-```bash
-git checkout <tag-name>
-```
-
-### 2. Create a new branch from the tag and make sure you name it with the correct semantic versioning pattern
-
-```bash
-git checkout -b release/<patched-tag-name>
-```
-
-### 3. Cherry-pick the commits or feature branches you want to add to the new release branch
-
-```bash
-git cherry-pick <commit-id>
-# OR
-git cherry-pick <feature-branch-name>
-```
-
-### 4. Go to "Repository > Releases" in GitLab and click "New release"
-
-- Follow the same process as above for the usual tag, but instead of `master`, select the `release/<patched-tag-name>` branch in the “Create from” dropdown
-
-### 5. Merge the release branch back into master after it has been deployed
-
----
-
-## Releasing a canary version
-
-This guide is for you if you want to create a release to test your unmerged changes in a different project without affecting the latest stable GDS version for other consumers.
-
-This is overkill for small UI changes, but a good usecase is for testing bigger/riskier changes in a demo environment before officially releasing them.
-
-In this example, the current stable release: `19.0.0` and your current branch name: `GDS-22-your-work`
-
-### 1. Go to "[Deployments > Releases](https://git.tmaws.io/global-design-system/gds/-/releases)" in GitLab and click "New release"
-
-### 2. Create a new tag with the name of the canary version
-
-It must be in this format: `<stable version>-canary.<canary version>`
-
-In our case we want to make a minor release in the future, so we enter `19.1.0-canary.1`.
-
-**Note:** the format is important because the regex we use in the `publish` script is:
-
-```yml
-# Get the npm tag from the version name (e.g. 7.0.0-canary.2 -> canary)
-- export NPM_TAG=$(echo $CI_COMMIT_TAG | sed -nE 's/.*-(.*)\.[0-9]+/\1/p')
-- npm publish --tag=${NPM_TAG:-latest}
-```
-
-If it doesn't match, it will create an unwanted stable tag.
-
-### 3. Select the branch where you make the release from (not master)
-
-In this case, we select `GDS-22-your-work`.
-
-### 4. Paste the release notes into the tag message and Release notes fields as usual
-
-### 5. Click "Create release"
-
-### 6. Check all went well
-
-Run this command where you have the `npmrc` file:
-
-```sh
-npm view @ticketmaster/global-design-system
-```
-
-You should see something like this:
-
-```sh
-dist tags:
-canary: 19.1.0-canary.1  latest: 19.0.0
-```
-
-**Note:** It is important that the `latest` tag is not the `canary` tag.
-
-### 7. You can now install the canary version in your project with:
-
-```sh
-npm i @ticketmaster/global-design-system@canary
-```