Gathering detailed insights and metrics for @reach/portal
Gathering detailed insights and metrics for @reach/portal
Gathering detailed insights and metrics for @reach/portal
Gathering detailed insights and metrics for @reach/portal
The Accessible Foundation for React Apps and Design Systems
npm install @reach/portal
Module System
Min. Node Version
Typescript Support
Node Version
NPM Version
5,976 Stars
1,684 Commits
560 Forks
56 Watching
8 Branches
143 Contributors
Updated on 26 Nov 2024
TypeScript (77.44%)
JavaScript (20.68%)
SCSS (0.84%)
CSS (0.74%)
HTML (0.26%)
Shell (0.05%)
Cumulative downloads
Total Downloads
Last day
-17.2%
78,136
Compared to previous day
Last week
1.2%
472,009
Compared to previous week
Last month
9%
1,929,943
Compared to previous month
Last year
-5.4%
24,573,413
Compared to previous year
1
Thanks for getting involved with Reach UI development!
Reach UI is built and tested with Yarn. Please follow their install instructions to get Yarn installed on your system.
Then, run these commands:
git clone git@github.com:reach/reach-ui.git
cd reach-ui
pnpm install
pnpm build
1pnpm build # builds all packages 2pnpm dev # starts storybook server 3pnpm test # runs tests in all packages
First do the steps in "Getting started", then start the Storybook server:
pnpm dev
Next, put a file in packages/<component-dir>/examples/<name>.example.js
and make it look like this:
1import * as React from "react"; 2 3// The name of the example (always name the variable `name`) 4let name = "Basic"; 5 6// The example to render (always name the function `Example`) 7function Example() { 8 return <div>Cool cool cool</div>; 9} 10 11// Assign the name to the example and then export it as a named constant 12Example.storyName = name; 13export const Basic = Example; 14 15// Default export an object with the title matching the name of the Reach package 16export default { title: "Dialog" };
Now you can edit the files in packages/*
and storybook will automatically reload your changes.
Note: If you change an internal dependency you will need to run yarn build
again. For example, if working on MenuButton
requires a change to Rect
(an internal dependency of MenuButton
), you will need to run yarn build
for the changes to Rect
to show up in your MenuButton
example.
First do the steps in "Getting Started", then:
pnpm test
Or if you want to run the tests as you edit files:
pnpm test --watch
Often you'll want to just test the component you're working on:
cd packages/<component-path>
pnpm test --watch
The components to be built come from the the Aria Practices Design Patterns and Widgets, with a few exceptions. Here is a table of the components and their status.
✅ - Released
🛠 - Building
Status | Name |
---|---|
✅ | Accordion |
✅ | Alert |
✅ | Alert Dialog |
✅ | Checkbox |
✅ | Combo Box |
✅ | Dialog (Modal) |
✅ | Disclosure |
🛠 | Hover Card |
✅ | Listbox |
✅ | Menu Button |
🛠 | Radio Group |
✅ | Slider |
✅ | Tabs |
🛠 | Toggletip |
✅ | Tooltip |
This is (was?) our current release process. It's not perfect, but it has almost the right balance of manual + automation for me. We might be able to put some of this in a script...
1$ git checkout main 2$ git pull origin main 3$ git checkout dev 4$ git pull origin dev 5$ git checkout -b release-<version> 6$ git merge main 7 8# Resolve any merge conflicts and commit if necessary 9 10# Run the build locally and make sure there are no problems 11$ pnpm build 12$ pnpm test 13 14# Check out the `main` branch and merge release changes from `dev` 15$ git checkout main 16$ git pull origin main 17$ git merge dev 18 19# Write the changelog based on commits. We'll automate this part 20# eventually, but for now this is manual. 21 22# Then create a new version and git tag locally. Don't push yet! 23$ pnpm ver [version] 24 25# Take a look around and make sure everything is as you'd expect. 26# You can inspect everything from the commit that lerna made with: 27$ git log -p 28 29# If something needs to be changed, you can undo the commit and 30# delete the tag that lerna created and try again. 31 32# If everything looks good, push to GitHub along with the new tag: 33$ git push origin main --follow-tags 34 35# Open up https://github.com/reach/reach-ui/actions and watch the build. There will 36# be 2 builds, one for the push to the main branch and one for the 37# new tag. The tag build will run the build and all the tests and then 38# automatically publish to npm if everything passes. If there's a 39# problem, we have to figure out how to fix manually. 40 41# Paste the changelog into the release on GitHub. The release is 42# complete … huzzah!
You need to be careful when publishing a new package because the lerna publish
on CI will fail for new packages. To get around this, you should publish a 0.0.0
version of the package manually ahead of time. Then the release from CI will be ok. This is really janky but AFAICT the only workaround.
Stuff I'd like to improve:
The website is a Gatsby app in the website
directory. It automatically deploys to https://reach.tech/ when the website
branch is updated.
No vulnerabilities found.
Reason
no dangerous workflow patterns detected
Reason
no binaries found in the repo
Reason
license file detected
Details
Reason
Found 0/25 approved changesets -- score normalized to 0
Reason
0 commit(s) and 0 issue activity found in the last 90 days -- score normalized to 0
Reason
detected GitHub workflow tokens with excessive permissions
Details
Reason
no effort to earn an OpenSSF best practices badge detected
Reason
dependency not pinned by hash detected -- score normalized to 0
Details
Reason
security policy file not detected
Details
Reason
project is not fuzzed
Details
Reason
SAST tool is not run on all commits -- score normalized to 0
Details
Reason
branch protection not enabled on development/release branches
Details
Reason
125 existing vulnerabilities detected
Details
Score
Last Scanned on 2024-11-18
The Open Source Security Foundation is a cross-industry collaboration to improve the security of open source software (OSS). The Scorecard provides security health metrics for open source projects.
Learn More