Contributing

Contributions are welcome. dte-sdk produces legal tax documents and handles signing keys, so correctness and test coverage matter more than speed. This guide gets you set up.

Reporting issues#

Found a bug or have a feature request?

Search the existing issues first.
Open a new issue with a clear description, reproduction steps, expected vs. actual behavior, and a minimal code example.

When you attach XML or input objects, redact them: replace real RUTs, names and amounts with the example values used in these docs, and never attach a real CAF, certificate or password.

For security vulnerabilities, don't open a public issue. Follow the repository's private security policy instead. See Security.

Development setup#

Prerequisites#

Node.js 20 or later
npm
git

Get started#

Shell

git clone https://github.com/arrowsw/dte-sdk.git
cd dte-sdk
npm install
 
npm test          # run the test suite
npm run build     # build the ESM and CJS bundles
npm run lint      # lint the source and tests
npm run size      # check the bundle against its size budget

Submitting a pull request#

Branch

Shell

git checkout -b feature/my-feature

Implement with tests

Add tests for the new behavior: the happy path, every DteError code it can throw, and edge cases such as rounding, discounts and exempt lines. Coverage should not go down.

Verify locally

Shell

npm test
npm run lint
npm run build
npm run size

Commit and open the PR

Use a clear, conventional commit message. Describe the change, link the issue it addresses and call out any breaking impact on the public API.

Code guidelines#

Written in TypeScript; follow the existing style and run the linter.
Add JSDoc to every public function.
No runtime dependencies. Zero dependencies is part of the package's promise; open an issue before proposing one.
Web platform APIs only. Use Web Crypto, not node:crypto, so the same code runs on Node, Deno, Bun and the browser.
Money is integer CLP. Round half-up at the documented points and never let a floating-point amount reach the XML.
Preserve the security invariants: error messages stay generic and never echo RUTs, amounts, keys or passwords.

Test guidelines#

The suite is the contract: 412 tests in 14 suites, all passing. Mirror the existing structure:

TypeScript

describe('stampDte', () => {
  describe('happy path', () => {
    test('stamps a folio inside the CAF range', () => { /* … */ })
  })
  describe('errors', () => {
    test('throws FOLIO_OUT_OF_RANGE for a folio outside the range', () => { /* … */ })
    test('throws CAF_EXPIRED after the CAF expiry date', () => { /* … */ })
  })
  describe('edge cases', () => {
    test('accepts the first and last folio of the range', () => { /* … */ })
  })
})

Fixtures only. Tests use CAFs and certificates generated for testing. Never commit a real CAF, a real .pfx or a password.
Valid RUTs. Every RUT in a test must have a correct Modulo 11 check digit unless the test is about an invalid one. Reuse 76.123.456-0 and 77.654.321-7.
Exact amounts. Assert totals as exact integers; IVA rounding bugs hide in "close enough".

Project structure#

Code

dte-sdk/
├── src/          # Library source (single entry: index.ts)
├── tests/        # Test suites and fixtures
├── scripts/      # Build helpers
├── dist/         # Build output (ESM + CJS)
└── package.json

Updating the docs#

Spotted a mistake on this site? Open an issue with the page and the correction. When you add or change a feature in the package, please also:

Update the root README.md and CHANGELOG.md.
Include runnable code examples that use the documented example values.
Mention any change to a signature or error code in the PR description.

Areas that always help#

Tests: more edge cases around rounding, discounts, exempt lines and multi-document uploads.
Docs: clearer explanations, more examples, translations.
Tooling: CI, developer experience, release automation.

License#

Thank you for contributing. Your help makes electronic invoicing easier for every developer in Chile.

← PreviousSecurity