Magic-Mirror/js-beautify
1
0
Fork 0
mirror of https://github.com/beautifier/js-beautify.git synced 2025-01-31 09:52:17 +00:00
Code Issues Actions Packages Projects Releases Wiki Activity

Merge branch 'master' into master

Browse Source
This commit is contained in:
Liam Newman 2018-05-07 13:40:09 -07:00 committed by GitHub
commit 2fe0f8c8a8
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 18 additions and 17 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

35
CONTRIBUTING.md
View File

@ -5,34 +5,36 @@
If you find a bug, please report it, including environment and examples of current behavior and what you believe to be the correct behavior. The clearer your description and information, the more likely it is someone will be able to make progress on it. The default issue template will help guide you through this.
## How to Make Changes (Implement Fixes and New Features)
Fixes and enhancements are totally welcome. We prefer if you file an issue before filing a PR, as this gives us chance to discuss design details, but fee free to dive right in.
Fixes and enhancements are totally welcome. We prefer you to file an issue before filing a PR, as this gives us chance to discuss design details, but feel free to dive right in.
### 1. Build and Test Locally
While developing, you may build and test locally in JavaScript or Python implementation. The HTML beautifier is only implemented in JavaScript.
This repository holds two mostly identical implementations of the beautifiers: a JavaScript implementation and a Python implementation.
While developing, you may locally build and test the JavaScript or Python (or both). The HTML beautifier is only implemented in JavaScript.
* Familiarize yourself with the folder structure and code style before you dive in.
* Make changes to the implementation of your choice
* Make changes to the implementation of your choice.
* Add tests to `/test/data/*/test.js`.
* Run `./build jstest` or `./build pytest` to run style checks, and to generate and run tests.
* Include all changed files in your commit - The generated test files are checked in along with changes to the test data files.
### 2. Ensure Feature Parity
You must port changes to the other implementation. **This is required**. Every time we make an exception to this requirement the project becomes harder to maintain. If you find yourself making changes and find you cannot port them to the other implementation due to implementations being out of sync, you will begin to understand why this is required. We made this a requirement several years ago and there are still a open issues for changes that people at the time promised to port "in the next week or two". The entire HTML beautifier is an example of this. :(
Any changes made to one implementation must be also made to the other implementation. **This is required**. Every time we make an exception to this requirement the project becomes harder to maintain. This will become painfully clear, should you find yourself unable to port changes from one implementation to the other due to implementations being out of sync. We made this a requirement several years ago and there are **still** open issues for changes that people promised to port "in the next week or two". The entire HTML beautifier is an example of this. :(
The implementations are already very similar and neither Python nor JavaScript are that hard to understand. Take the plunge, it is easier than you think. If you get stuck, move on to filing a Pull Request and we can discuss how to move forward.
The implementations are already very similar and neither Python nor JavaScript are that hard to understand. Take the plunge, it is easier than you think. If you get stuck, go ahead and file a Pull Request and we can discuss how to move forward.
* Run `./build` (with no parameters) to run style checks, and to generate and run tests on both implementations.
* Include all changed files in your commit - The generated test files are checked in along with changes to the test data files.
### 3. Update Documentation and Tools
Update documentation as needed. This such as the README.md, internal command-line help, and file comments.
Also, check your change needs any tooling updates. For example, the CDN URLs required added scripting to update automatically for new releases.
Update documentation as needed. This includes files such as the README.md, internal command-line help, and file comments.
Also, check if your change needs any tooling updates. For example, the CDN URLs required additional scripting to update automatically for new releases.
### 4. Submit a Pull Request
* Run `./build full` locally after commit but before creation of Pull Request. You may start a Pull Request if this does not succeed, but the PR will not be accepted without additional changes.
* Run `./build full` locally after commit but before creation of Pull Request. You may start a Pull Request even if this reports errors, but the PR will not be merged until all errors are fixed.
* Include description of changes. Include examples of input and expected output if possible.
* Pull requests must pass build checks on all platforms before being accepted. We use Travis CI and AppVeyor to run tests on Linux and Windows, across multiple versions of Node.js and Python.
* Pull requests must pass build checks on all platforms before being merged. We use Travis CI and AppVeyor to run tests on Linux and Windows across multiple versions of Node.js and Python.
# Folders
@ -45,12 +47,11 @@ Files related to the JavaScript implementations of the beautifiers.
## `python`
Files related to the Python implementations of the beautifiers.
## `web`
Files related to http://jsbeautifier.org/.
## `test`
Test data files and support files used to generate implementation-specific test files from them.
Test data files and support files used to generate implementation-specific test files.
# Branches
@ -84,14 +85,14 @@ available on branch `attic-other`. Take a look and feel free to resurrect them,
dusty back there.
### Generic Eval Unpacker
The `attic-genericeval` branch includes an unpacker that call `eval` on whatever source is passed to it.
Useful when working with source that unpacks itself when eval is called on it, but also unsafe. We keep
it on this separate branch to keep it from hurting the other children.
The `attic-genericeval` branch includes an unpacker that calls `eval` on whatever source is passed to it.
This file may be useful when working with source that unpacks itself when `eval` is called on it, but is also very unsafe.
We have isolated it on this separate branch to keep it from hurting the other children.
# Publishing a Release
Each platform has it's own release process.
Each platform has its own release process.
NOTE: Before you do any of these make sure the latest changes have passed the Travis CI build!
NOTE: Before you do any of the following make sure the latest changes have passed the Travis CI build!
## Web
Merge changes from `master` to `gh-pages` branch. This is very low cost and can be done whenever is convenient.
@ -126,7 +127,7 @@ To perform these steps you will need:
1. An npmjs.org user account from https://npmjs.org/signup.
2. Permissions to the js-beautify module on npmjs.org. File an issue here on GitHub and the appropriate person will help you.
Npm makes this process even simpler than Python's and creates a tag for the release as well.
NPM makes this process even simpler than Python's and also creates a tag for the release.
```bash
git clean -xfd