11# scratch-parser
22
3- #### Parser for Scratch projects
3+ Parser for Scratch projects
44
5- [ ![ Build Status] ( https://travis-ci.org/LLK/scratch-parser.svg?branch=develop )] ( https://travis-ci.org/LLK/scratch-parser )
6- [ ![ dependencies Status] ( https://david-dm.org/llk/scratch-parser/status.svg )] ( https://david-dm.org/llk/scratch-parser )
7- [ ![ devDependencies Status] ( https://david-dm.org/llk/scratch-parser/dev-status.svg )] ( https://david-dm.org/llk/scratch-parser?type=dev )
5+ [ ![ CircleCI] ( https://circleci.com/gh/LLK/scratch-parser.svg?style=shield )] ( https://app.circleci.com/pipelines/github/LLK/scratch-parser?branch=master )
86
97## Overview
10- The Scratch Parser is a [ Node.js] ( https://nodejs.org ) module that parses and validates [ Scratch] ( https://scratch.mit.edu ) projects.
8+
9+ The Scratch Parser is a [ Node.js] ( https://nodejs.org ) module that parses and validates
10+ [ Scratch] ( https://scratch.mit.edu ) projects.
1111
1212## API
1313
14- #### Installation
15- ``` bash
14+ ### Installation
15+
16+ ``` sh
1617npm install scratch-parser
1718```
1819
19- #### Basic Use
20+ ### Basic Use
21+
2022``` js
2123var fs = require (' fs' );
2224var parser = require (' scratch-parser' );
@@ -28,8 +30,10 @@ parser(buffer, function (err, project) {
2830});
2931```
3032
31- #### "Info"
32- In addition to the ` _meta ` data described above, Scratch projects include an attribute called ` info ` that * may* include the following:
33+ ### "Info"
34+
35+ In addition to the ` _meta ` data described above, Scratch projects include an attribute called ` info ` that * may*
36+ include the following:
3337
3438| Key | Description |
3539| ----------------- | -------------------------------------------------------- |
@@ -40,30 +44,35 @@ In addition to the `_meta` data described above, Scratch projects include an att
4044
4145## Testing
4246
43- #### Running the Test Suite
44- ``` bash
47+ ### Running the Test Suite
48+
49+ ``` sh
4550npm test
4651```
4752
48- #### Code Coverage Report
49- ``` bash
53+ ### Code Coverage Report
54+
55+ ``` sh
5056make coverage
5157```
5258
53- #### Performance Benchmarks / Stress Testing
54- ``` bash
59+ ### Performance Benchmarks / Stress Testing
60+
61+ ``` sh
5562make benchmark
5663```
5764
5865## Committing
66+
5967This project uses [ semantic release] ( https://github.com/semantic-release/semantic-release )
6068to ensure version bumps follow semver so that projects using the config don't
6169break unexpectedly.
6270
6371In order to automatically determine the type of version bump necessary, semantic
6472release expects commit messages to be formatted following
6573[ conventional-changelog] ( https://github.com/bcoe/conventional-changelog-standard/blob/master/convention.md ) .
66- ```
74+
75+ ``` text
6776<type>(<scope>): <subject>
6877<BLANK LINE>
6978<body>
@@ -76,6 +85,7 @@ where you would include `BREAKING CHANGE` and `ISSUES FIXED` sections if
7685applicable.
7786
7887` type ` is one of:
88+
7989* ` fix ` : A bug fix ** Causes a patch release (0.0.x)**
8090* ` feat ` : A new feature ** Causes a minor release (0.x.0)**
8191* ` docs ` : Documentation only changes
@@ -90,14 +100,15 @@ applicable.
90100Use the [ commitizen CLI] ( https://github.com/commitizen/cz-cli ) to make commits
91101formatted in this way:
92102
93- ``` bash
103+ ``` sh
94104npm install -g commitizen
95105npm install
96106```
97107
98108Now you're ready to make commits using ` git cz ` .
99109
100110## Breaking changes
111+
101112If you're committing a change that will require changes to existing code, ensure
102113your commit specifies a breaking change. In your commit body, prefix the changes with "BREAKING CHANGE: "
103114This will cause a major version bump so downstream projects must choose to upgrade
0 commit comments