Contributing

noteloom is free and open-source, and it stays useful because people file issues, fix bugs, and add features. Contributions of any size — a typo fix, a failing-test report, a whole new block type — are welcome.

Two repositories

• The editor itself — noteloom. This is where noteloom's source, tests, and build live.
• This site — the marketing page, documentation, Playground, and the offline Notes app you might be using right now. It's a separate repository so it can be deployed independently of the package itself, and it uses noteloom as a normal dependency (its own Playground/Notes pages are the library running in production, not a special internal build).

Local setup (editor package)

git clone https://github.com/vishwakarmanikhil/noteloom.git
cd noteloom
npm install
npm run dev     # examples/basic dev server
npm test        # vitest (jsdom + @testing-library/react)
npm run build   # library build (dist/, ESM + CJS)

Local setup (this site)

This is a fully independent repository — it depends on noteloom as a normal published npm package, not a local checkout of the editor repo above:

npm install
npm run dev      # http://localhost:5183
npm run build    # static export to /out

Working on the editor package and this site together and want the site to pick up unpublished changes? Point package.json's noteloom dependency at a local path instead (e.g. "noteloom": "file:../noteloom", with the package cloned as a sibling directory and built via npm run build), then switch it back to the published version range before committing.

Guidelines

• Open an issue before starting a large change (a new block type, a breaking API change) so the approach can be discussed first — smaller fixes and clear bugs can go straight to a PR.
• Add or update tests for anything behavioral. npm test should pass before you open a PR.
• Match the existing code style — no bundled formatter/linter config is enforced beyond what's already there, so mirror the surrounding file.
• Keep PRs focused. A bug fix doesn't need an unrelated refactor riding along with it.
• Describe why in your commit messages and PR description, not just what changed — the diff already shows what changed.

Where to start

Check the issue tracker for open bugs and feature requests. The package's own README also documents current known limitations — several of those are good first contributions (e.g. accessibility gaps around list grouping, atomic cross-block undo steps).

Reporting a bug

Please include: the noteloom version, your browser/OS, and the smallest possible reproduction (a snippet or a link to a fork of the Playground/Notes page is ideal — jsdom-based automated tests can't catch real-browser contentEditable quirks, so exact repro steps matter).