2016-03-18 19:51:40 -04:00
|
|
|
# scratch-parser
|
2018-04-11 17:21:37 -04:00
|
|
|
|
2022-11-23 09:54:44 -08:00
|
|
|
Parser for Scratch projects
|
2016-03-15 10:31:35 -04:00
|
|
|
|
2022-11-23 09:54:44 -08:00
|
|
|
[](https://app.circleci.com/pipelines/github/LLK/scratch-parser?branch=master)
|
2016-03-15 10:31:35 -04:00
|
|
|
|
2016-03-18 19:51:40 -04:00
|
|
|
## Overview
|
2022-11-23 09:54:44 -08:00
|
|
|
|
|
|
|
The Scratch Parser is a [Node.js](https://nodejs.org) module that parses and validates
|
|
|
|
[Scratch](https://scratch.mit.edu) projects.
|
2016-03-15 10:31:35 -04:00
|
|
|
|
2016-03-18 19:51:40 -04:00
|
|
|
## API
|
2016-03-15 10:31:35 -04:00
|
|
|
|
2022-11-23 09:54:44 -08:00
|
|
|
### Installation
|
|
|
|
|
|
|
|
```sh
|
2016-03-18 19:51:40 -04:00
|
|
|
npm install scratch-parser
|
2016-03-15 10:31:35 -04:00
|
|
|
```
|
|
|
|
|
2022-11-23 09:54:44 -08:00
|
|
|
### Basic Use
|
|
|
|
|
2016-03-15 10:31:35 -04:00
|
|
|
```js
|
|
|
|
var fs = require('fs');
|
2016-03-18 20:39:41 -04:00
|
|
|
var parser = require('scratch-parser');
|
2016-03-15 10:31:35 -04:00
|
|
|
|
2016-03-18 19:51:40 -04:00
|
|
|
var buffer = fs.readFileSync('/path/to/project.sb2');
|
2019-10-03 17:44:04 +02:00
|
|
|
parser(buffer, false, function (err, project) {
|
2016-03-15 10:31:35 -04:00
|
|
|
if (err) // handle the error
|
|
|
|
// do something interesting
|
|
|
|
});
|
|
|
|
```
|
|
|
|
|
2022-11-23 09:54:44 -08:00
|
|
|
### "Info"
|
|
|
|
|
|
|
|
In addition to the `_meta` data described above, Scratch projects include an attribute called `info` that *may*
|
|
|
|
include the following:
|
2016-03-18 19:51:40 -04:00
|
|
|
|
|
|
|
| Key | Description |
|
|
|
|
| ----------------- | -------------------------------------------------------- |
|
|
|
|
| `flashVersion` | Installed version of Adobe Flash |
|
|
|
|
| `swfVersion` | Version of the Scratch editor used to create the project |
|
|
|
|
| `userAgent` | User agent used to create the project |
|
|
|
|
| `savedExtensions` | Array of Scratch Extensions used in the project |
|
|
|
|
|
2016-03-15 10:31:35 -04:00
|
|
|
## Testing
|
2016-03-18 19:51:40 -04:00
|
|
|
|
2022-11-23 09:54:44 -08:00
|
|
|
### Running the Test Suite
|
|
|
|
|
|
|
|
```sh
|
2016-03-15 10:31:35 -04:00
|
|
|
npm test
|
|
|
|
```
|
2016-03-18 19:51:40 -04:00
|
|
|
|
2022-11-23 09:54:44 -08:00
|
|
|
### Code Coverage Report
|
|
|
|
|
|
|
|
```sh
|
2016-03-18 19:51:40 -04:00
|
|
|
make coverage
|
|
|
|
```
|
|
|
|
|
2022-11-23 09:54:44 -08:00
|
|
|
### Performance Benchmarks / Stress Testing
|
|
|
|
|
|
|
|
```sh
|
2016-03-18 19:51:40 -04:00
|
|
|
make benchmark
|
|
|
|
```
|
2017-03-21 15:42:32 -04:00
|
|
|
|
|
|
|
## Committing
|
2022-11-23 09:54:44 -08:00
|
|
|
|
2017-03-21 15:42:32 -04:00
|
|
|
This project uses [semantic release](https://github.com/semantic-release/semantic-release)
|
|
|
|
to ensure version bumps follow semver so that projects using the config don't
|
|
|
|
break unexpectedly.
|
|
|
|
|
|
|
|
In order to automatically determine the type of version bump necessary, semantic
|
|
|
|
release expects commit messages to be formatted following
|
|
|
|
[conventional-changelog](https://github.com/bcoe/conventional-changelog-standard/blob/master/convention.md).
|
2022-11-23 09:54:44 -08:00
|
|
|
|
|
|
|
```text
|
2017-03-21 15:42:32 -04:00
|
|
|
<type>(<scope>): <subject>
|
|
|
|
<BLANK LINE>
|
|
|
|
<body>
|
|
|
|
<BLANK LINE>
|
|
|
|
<footer>
|
|
|
|
```
|
|
|
|
|
|
|
|
`subject` and `body` are your familiar commit subject and body. `footer` is
|
|
|
|
where you would include `BREAKING CHANGE` and `ISSUES FIXED` sections if
|
|
|
|
applicable.
|
|
|
|
|
|
|
|
`type` is one of:
|
2022-11-23 09:54:44 -08:00
|
|
|
|
2017-03-21 15:42:32 -04:00
|
|
|
* `fix`: A bug fix **Causes a patch release (0.0.x)**
|
|
|
|
* `feat`: A new feature **Causes a minor release (0.x.0)**
|
|
|
|
* `docs`: Documentation only changes
|
|
|
|
* `style`: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc)
|
|
|
|
* `refactor`: A code change that neither fixes a bug nor adds a feature
|
|
|
|
* `perf`: A code change that improves performance **May or may not cause a minor release. It's not clear.**
|
|
|
|
* `test`: Adding missing tests or correcting existing tests
|
|
|
|
* `ci`: Changes to our CI configuration files and scripts (example scopes: Travis, Circle, BrowserStack, SauceLabs)
|
|
|
|
* `chore`: Other changes that don't modify src or test files
|
|
|
|
* `revert`: Reverts a previous commit
|
|
|
|
|
|
|
|
Use the [commitizen CLI](https://github.com/commitizen/cz-cli) to make commits
|
|
|
|
formatted in this way:
|
|
|
|
|
2022-11-23 09:54:44 -08:00
|
|
|
```sh
|
2017-03-21 15:42:32 -04:00
|
|
|
npm install -g commitizen
|
|
|
|
npm install
|
|
|
|
```
|
|
|
|
|
|
|
|
Now you're ready to make commits using `git cz`.
|
|
|
|
|
|
|
|
## Breaking changes
|
2022-11-23 09:54:44 -08:00
|
|
|
|
2017-03-21 16:24:45 -04:00
|
|
|
If you're committing a change that will require changes to existing code, ensure
|
|
|
|
your commit specifies a breaking change. In your commit body, prefix the changes with "BREAKING CHANGE: "
|
2017-03-21 15:42:32 -04:00
|
|
|
This will cause a major version bump so downstream projects must choose to upgrade
|
|
|
|
the config and will not break the build unexpectedly.
|