Ecosyste.ms: Awesome
An open API service indexing awesome lists of open source software.
https://github.com/srijan-paul/jam
An ultra-fast and robust parser, formatter, code optimizer, and linter for the JS ecosystem
https://github.com/srijan-paul/jam
javascript linter toolchain zig
Last synced: 3 days ago
JSON representation
An ultra-fast and robust parser, formatter, code optimizer, and linter for the JS ecosystem
- Host: GitHub
- URL: https://github.com/srijan-paul/jam
- Owner: srijan-paul
- License: other
- Created: 2024-10-14T17:02:23.000Z (4 months ago)
- Default Branch: main
- Last Pushed: 2025-01-26T16:10:32.000Z (13 days ago)
- Last Synced: 2025-01-29T18:51:09.677Z (10 days ago)
- Topics: javascript, linter, toolchain, zig
- Language: Zig
- Homepage:
- Size: 3.42 MB
- Stars: 104
- Watchers: 2
- Forks: 2
- Open Issues: 0
-
Metadata Files:
- Readme: README.md
- License: LICENSE
Awesome Lists containing this project
README
# Jam
A high-performance JavaScript toolchain built from the ground up.
**Work in progress!**
## Goals
- Faster than (or very close to) existing tools.
- Low memory footprint.
- Support JS, JSX, TypeScript, and CSS out of the box.
- Support data flow analysis and call-graphs with an accessible API.
- API for writing linting rules in Zig.
- Expose a capable parsing and scoping library, such that a bundler, minifier, etc., can be built on top of it.
- Custom JS plugins.
(I plan to embed the [Kiesel](https://kiesel.dev) JS engine).
## Roadmap
- Phase 1:
- [x] A fast, 100% Spec compliant JavaScript parser.
- [ ] JSX support (**Under construction**)
- [ ] TypeScript support in the parser.
- [ ] Port [ESLint scope](https://github.com/eslint/js/tree/main/packages/eslint-scope) to Zig
- [ ] Runtime for a linter, with Zig plugin support.
- Alpha release
- [ ] Simple linter with all the base rules from ESLint.
- [ ] A prototype of a formatter
- Beta release
- [ ] Data flow analysis and taint checking
## Local development
I've tried to keep the development process hassle-free.
You need only a Zig compiler (and optionally an environment variable) to get going.
If you still face any issues, feel free to open an issue
or reach out to me on discord (`@injuly.`), twitter (`@ptrCast`), or e-mail (`[email protected]`).
I usually respond within a day.
> **NOTE:** If you're willing to contribute, It's a good idea to copy the contents of ./pre-commit to
your `./.git/hooks/pre-commit`.
> This will ensure you didn't break any existing functionality before letting you commit changes.
### Basic setup
1. Ensure you have a `master` build of the zig compiler –
to seamlessly switch between multiple zig versions, I recommend using [zvm](https://github.com/tristanisham/zvm).
2. Clone this project into your development machine.
3. Run `zig build run -- ` to see a parsed AST for the given file.
4. Run `zig build test` to run the unit tests.
### Checking ECMAScript conformance
To avoid regressions and keep track of spec compliance, we use a `results.json` file,
the format for which is further explained in the [tests262 runner's README](./tools/README.md).
You'll need to set the `JAM_TESTS_262_DIR` environment variable to the path of a cloned [tc39/test262-parser-tests](https://github.com/tc39/test262-parser-tests) repository:
```sh
git clone --depth 1 https://github.com/tc39/test262-parser-tests.git /tmp/test262-parser-tests
# `tools/ec262-tests` can find the tests if you set the environment variable.
export JAM_TESTS_262_DIR=/tmp/test262-parser-tests
```
To compare your changes with the existing test results, run `zig build test262 -- compare ./tools/results.json`.
If it exits with a zero status code, you didn't break anything!
To update the test results, run `zig build test262 > ./tools/results.json`.
Currently, the format of the `results.json` file is roughly as follows:
```js
{
// % of test files that either: a) parsed incorrectly, or b) failed to parse.
"fail_percent": 35.703479576399396,
// % of test files that were parsed correctly.
"pass_percent": 64.2965204236006,
// number of test files that parsed but had an incorrect syntax tree.
"unmatching_ast_count": 17,
// results for individual test cases:
"test_cases": {
"2db5219f0ac5dd71.js": "parse_error",
"c532e126a986c1d4.js": "pass",
"d532e126a986c1d4.js": "ast_no_match",
// ...goes on for a few thousand lines...
```