Gathering detailed insights and metrics for @musical-patterns/playroom
Gathering detailed insights and metrics for @musical-patterns/playroom
Gathering detailed insights and metrics for @musical-patterns/playroom
Gathering detailed insights and metrics for @musical-patterns/playroom
npm install @musical-patterns/playroom
Typescript
Module System
Node Version
NPM Version
TypeScript (86.73%)
SCSS (9.77%)
HTML (3.1%)
JavaScript (0.37%)
Self (0.03%)
Total Downloads
0
Last Day
0
Last Week
0
Last Month
0
Last Year
0
MIT License
697 Commits
1 Watchers
2 Branches
1 Contributors
Updated on Apr 17, 2025
Latest Version
1.0.426
Package Id
@musical-patterns/playroom@1.0.426
Unpacked Size
2.74 MB
Size
1.13 MB
File Count
239
NPM Version
8.15.0
Node Version
16.17.0
Cumulative downloads
Total Downloads
Last Day
0%
NaN
Compared to previous day
Last Week
0%
NaN
Compared to previous week
Last Month
0%
NaN
Compared to previous month
Last Year
0%
NaN
Compared to previous year
28
The web-based UI for playing (with) the patterns.
Just call setupPlayroom
with whichever patterns you want.
Similar to the @musical-patterns/cli
repo, upon installation, copies playroom files into the pattern repo.
These files are:
import { setupPlayroom } from '@musical-patterns/playroom'
import { Patterns } from '@musical-patterns/pattern'
const patterns: Patterns = {
// your patterns here
}
const playroom: HTMLDivElement = await setupPlayroom(patterns)
document.body.appendChild(playroom)
The second optional argument to setupPlayroom
is debug mode, a boolean defaulting to false, which will log information about the compiled pattern to the developer console.
You can start the local playroom
server either by running make start
or by running make test
. The server runs on port 8082 either way.
The key difference between the two commands is that make test
will run the test suite and leave the server running as a background process afterward.
On the other hand, make start
stays foregrounded, and does nothing else besides start the server.
When the tests are run, if the playroom
is already running, it will test against the already running server, to save time.
So as opposed to relying on the test
command's backgrounded process, using start
has the benefit of giving you a console window view into the state of the server,
for viewing of webpack
compilation errors during development, and a quick Ctrl-C to kill the server.
However there is a caveat. The two commands start the local server in two different modes: development, and test, respectively.
Currently there is almost no difference between the two modes. However there is one difference which is significant enough to cause one of the tests to fail.
The playroom
's current implementation of WebXR code is not supported in the automated browser environment, so in test mode it tricks the app into thinking it is.
If you feel confident about it, maybe just ignore this test if you find yourself having run the test suite against a development server.
No vulnerabilities found.
Reason
no binaries found in the repo
Reason
license file detected
Details
Reason
2 commit(s) and 0 issue activity found in the last 90 days -- score normalized to 1
Reason
no effort to earn an OpenSSF best practices badge detected
Reason
security policy file not detected
Details
Reason
project is not fuzzed
Details
Reason
branch protection not enabled on development/release branches
Details
Reason
SAST tool is not run on all commits -- score normalized to 0
Details
Reason
17 existing vulnerabilities detected
Details
Score
Last Scanned on 2025-07-14
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