|
| 1 | +# Contributing to Stacklyn |
| 2 | + |
| 3 | +First off, thank you for wanting to help out :D |
| 4 | + |
| 5 | +## Getting Started |
| 6 | + |
| 7 | +```bash |
| 8 | +git clone https://github.com/stacklynjs/stacklyn.git |
| 9 | +``` |
| 10 | + |
| 11 | +Then do your changes, simple as that! |
| 12 | + |
| 13 | +To build `stacklyn.min.js`, you can do either: |
| 14 | +- `node build.js` (fast and direct) |
| 15 | +- `npm run build` (standard, but slower imo) |
| 16 | + |
| 17 | +Both go to build.js anyway. |
| 18 | + |
| 19 | +If you're wondering why `dist` only has one lone file, it's for future proofing in case someone says "make an es6 polyfill version pls". |
| 20 | + |
| 21 | +## What to avoid |
| 22 | + |
| 23 | +Please avoid suggesting, or making PRs that: |
| 24 | +- Add support for a JS engine no one uses |
| 25 | + - **optional but recommended:** |
| 26 | + If it can't run Stacklyn feasibly (e.g. you *have* to do some steps before getting to do anything) then that JS engine would also be discarded. |
| 27 | +- Add parsing for formats that are undetectable, exactly the same, or too similar to a format already parsed |
| 28 | + - E.g. a format that starts with four spaces and an at. This is already handled and the PR will get closed. |
| 29 | + - If the trace format has special marks like `<unknown>` you could put an `if` statement in the parser at MOST. |
| 30 | + - While those cases are fine, if there's trace formats of different engines that have the same marks, don't add detection for them. |
| 31 | +- Add features unrelated to the core purpose (error handling or stack traces) |
| 32 | +- Introduce frameworks or dependencies (Stacklyn is meant to be zero-dependency) |
| 33 | +- Format the code in an unnecessary way or dont fit the style guide listed below |
| 34 | + |
| 35 | +## Style Guide |
| 36 | +This is meant to be a guide, but it's heavily recommended you follow this for your PRs to get accepted. |
| 37 | + |
| 38 | +- Use 4 spaces for indentation. |
| 39 | +- Try to keep lines under 100 characters. |
| 40 | +- Prefer readable code when possible |
| 41 | +- Include semicolons at the end of statements where possible |
| 42 | +- Don't explain the obvious, for example: |
| 43 | + ```js |
| 44 | + function addNumbers(a, b) { // defines a function called addNumbers that takes a and b |
| 45 | + return a + b; // adds a and b together and returns the result |
| 46 | + } // end of function |
| 47 | + ``` |
| 48 | + Your code should generally be able to explain itself. |
| 49 | +- Minimize empty lines unless they break up logic meaningfully. |
| 50 | + |
| 51 | +## Testing |
| 52 | +There's no test suite, but here's how I tested my stuff: |
| 53 | + |
| 54 | +1. Chrome can hide bugs, so I tried the code on Firefox and Node. |
| 55 | +2. If it works the same way in both, your change is good to go! |
| 56 | + |
| 57 | +## Known Issues |
| 58 | +Not everything is perfect, Stacklyn has bugs too. |
| 59 | +Luckily they're not the game-over bugs, they're little edge cases I'm just not wanting to deal with at the moment as they require complex solutions. |
| 60 | + |
| 61 | +### 1. Eval-to-eval conversions result in malformed frames |
| 62 | +I can't easily convert between both eval formats at the moment. |
| 63 | +Eval stack traces are complicated, no matter how easy it seems on the surface. |
| 64 | + |
| 65 | +If you find a solution, make a PR! |
| 66 | +The issue number is #1. |
| 67 | + |
| 68 | +### 2. When parsing Opera/Espruino stack traces, lines with `\n` inside strings or comments get split incorrectly. |
| 69 | +This sounds like a simple issue but I have no idea how it'd be fixed. |
| 70 | + |
| 71 | +Those are the ones I know about at the moment, they're marked with `// BUG:` so you can easily find them! |
| 72 | + |
| 73 | +## Bugs and Suggestions |
| 74 | + |
| 75 | +If you find a bug or want to suggest something to be in the next version, feel free to open an issue. I'll respond when possible! |
| 76 | + |
| 77 | +If you're reporting a bug with an existing parser or converter, include a sample stack trace. |
| 78 | +Also, try to use labels when creating PRs or issues. |
| 79 | + |
| 80 | +### Want to maintain Stacklyn? |
| 81 | +I don't want to be the only maintainer, if you want to help make Stacklyn better, email me at `[email protected]` and I'll look into it! |
| 82 | + |
| 83 | +Thanks for helping improve Stacklyn, you're awesome :D |
0 commit comments