Gathering detailed insights and metrics for @spectrum-web-components/base
Gathering detailed insights and metrics for @spectrum-web-components/base
Gathering detailed insights and metrics for @spectrum-web-components/base
Gathering detailed insights and metrics for @spectrum-web-components/base
npm install @spectrum-web-components/base
Typescript
Module System
Node Version
NPM Version
92
Supply Chain
82.2
Quality
98.6
Maintenance
100
Vulnerability
72.1
License
TypeScript (56.93%)
CSS (37.63%)
JavaScript (5.22%)
HTML (0.17%)
Handlebars (0.05%)
Total Downloads
1,063,153
Last Day
552
Last Week
7,931
Last Month
67,252
Last Year
587,511
1,309 Stars
4,576 Commits
206 Forks
49 Watching
149 Branches
342 Contributors
Minified
Minified + Gzipped
Latest Version
1.0.3
Package Id
@spectrum-web-components/base@1.0.3
Unpacked Size
101.69 kB
Size
20.48 kB
File Count
59
NPM Version
10.8.1
Node Version
20.16.0
Publised On
12 Dec 2024
Cumulative downloads
Total Downloads
Last day
-78.1%
552
Compared to previous day
Last week
-42.9%
7,931
Compared to previous week
Last month
-27.9%
67,252
Compared to previous month
Last year
115.9%
587,511
Compared to previous year
1
The SpectrumElement
base class as created by mixing SpectrumMixin
onto LitElement
adopts dir
values from the document
at connection time with a fallback to lrt
. In a TypeScript context, it also enforces the presence of this.shadowRoot
on extending components.
yarn add @spectrum-web-components/base
When looking to leverage the SpectrumElement
base class as a type and/or for extension purposes, do so via:
import { SpectrumElement } from '@spectrum-web-components/base';
export MyElement extends SpectrumElement {}
Similarly the SpectrumMixin
class factory mixin is available via:
import { SpectrumMixin } from '@spectrum-web-components/base';
export MyElement extends SpectrumMixin(HTMLElement) {}
dir
managementWith powerful CSS selectors like :host(:dir(rtl))
and :host-content([dir=rtl])
not yet enjoying cross-browser support, reliably delivering content in both "left to right" and "right to left" while relying on Shadow DOM means certain trade offs need to be made. While every custom element build from SpectrumMixin
could have its dir
attribute applied to manage this, doing so is not only a pain for apply, it's a pain to maintain over time. To support the flexibility to deliver content in both of these directions, elements built from SpectrumMixin
will observe the dir
attribute of either the document
or a containing sp-theme
. This will allow your sites and applications to manage content direction in a single place while also opening the possibility of having multiple content directions on the same page by scoping those content sections with sp-theme
elements.
Placing a dir
attribute on an element built from SpectrumMixin
before attaching it to the DOM will prevent it from resolving the text direction value to a parent sp-theme
or document
element. Elements applied to the page in this way will also NOT participate in observing any such elements, so their dir
values will remain as initialized regardless of changes in other parts of your documents. If you choose to leverage this, be aware that any child (in both light DOM and shadow DOM) of this element will need to have a dir
attribute applied as well if you do not want it resolving to a parent sp-theme
or document
element itself. In this way, it is likely that you would benefit from leveraging an sp-theme
element to create scope in your document for managing this custom content direction section of your page.
isLTR
While CSS offers many powerful solutions for styling content in various directions, sometimes JS functionality depends on the specific of that direction. Elements built from SpectrumMixin
have the this.isLTR
getter that will resolve to true
when dir === 'ltr'
.
Elements built from SpectrumMixin
assume that you will be using shadow DOM in the resulting custom element. To simplify TypeScript usage the presence of this.shadowRoot
is asserted as non-null so that you have direct access to it without extended type checking.
No vulnerabilities found.
Reason
no dangerous workflow patterns detected
Reason
30 commit(s) and 13 issue activity found in the last 90 days -- score normalized to 10
Reason
license file detected
Details
Reason
no binaries found in the repo
Reason
security policy file detected
Details
Reason
Found 23/25 approved changesets -- score normalized to 9
Reason
no effort to earn an OpenSSF best practices badge detected
Reason
detected GitHub workflow tokens with excessive permissions
Details
Reason
dependency not pinned by hash detected -- score normalized to 0
Details
Reason
project is not fuzzed
Details
Reason
SAST tool is not run on all commits -- score normalized to 0
Details
Reason
29 existing vulnerabilities detected
Details
Score
Last Scanned on 2024-12-23
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