forge-sql-orm

Repository on GitHub, which provides public git repositories with URLs.

Repository on GitHub, which uses git. git can track the changes, who made them, and when they were made.

The public Git repository contains the full interim history, not only releases: work happens in feature branches and pull requests (https://github.com/forge-sql-orm/forge-sql-orm/pulls) and every commit to master is visible. Between releases, interim builds are also published automatically for testing: a weekly snapshot of master to GitHub Packages (dist-tag "latest", .github/workflows/weekly-gpr.yml) and a weekly snapshot of the Drizzle v1 line (dist-tag "drizzle-v1", .github/workflows/weekly-gpr.v1.yml). Final releases (e.g. 2.2.5) are published separately at https://github.com/forge-sql-orm/forge-sql-orm/releases.

Weekly Builds:
https://github.com/forge-sql-orm/forge-sql-orm/pkgs/npm/forge-sql-orm
https://github.com/forge-sql-orm/forge-sql-orm/pkgs/npm/forge-sql-orm-cli
https://github.com/forge-sql-orm/forge-sql-orm/pkgs/npm/forge-sql-orm-extra

Repository on GitHub, which uses git. git is distributed.

Every release has a unique version (2.2.3, 2.2.4, 2.2.5, ...).

Each release is identified by a Git tag matching its version number (e.g. 2.2.3, 2.2.4, 2.2.5); the repository has 51 tags: https://github.com/forge-sql-orm/forge-sql-orm/tags. Each GitHub Release is attached to its tag, for example https://github.com/forge-sql-orm/forge-sql-orm/releases/tag/2.2.5.

Every release has human-readable release notes grouped by theme (New, Improvements, Dependency Updates), not raw git log output. They are published on the GitHub Releases page (https://github.com/forge-sql-orm/forge-sql-orm/releases, e.g. https://github.com/forge-sql-orm/forge-sql-orm/releases/tag/2.2.5) and mirrored in CHANGELOG.md (https://github.com/forge-sql-orm/forge-sql-orm/blob/master/CHANGELOG.md). The notes describe user-visible changes and their impact, for example new APIs, behaviour changes and etc...

No publicly known vulnerabilities in the project's own code have been fixed so far

Non-trivial SECURITY[.md] file found file in repository: https://github.com/forge-sql-orm/forge-sql-orm/blob/master/SECURITY.md. [osps_do_02_01]

GitHub Issues: https://github.com/forge-sql-orm/forge-sql-orm/issues

I acknowledge bug reports quickly, usually the same day. Reports from the last 12 months: #1422 (https://github.com/forge-sql-orm/forge-sql-orm/issues/1422) was answered on the day it was opened; #2128 (https://github.com/forge-sql-orm/forge-sql-orm/issues/2128) was answered within hours, fixed in 2.1.28 (node-sql-parser moved to optionalDependencies), and then led to an architectural change in 2.2.0 (cache, Rovo and node-sql-parser moved out of core into the optional forge-sql-orm-extra package, tracked in #2321, #2326 and #2332). Older report #177 (https://github.com/forge-sql-orm/forge-sql-orm/issues/177) was answered in 3 days.

I respond to enhancement requests and questions. In the last 12 months the project received few external requests, and all were answered: Discussion #2271 (https://github.com/forge-sql-orm/forge-sql-orm/discussions/2271) about cache expiry was answered, and #2768 (https://github.com/forge-sql-orm/forge-sql-orm/issues/2768, option to silence applySchemaMigrations logs) was answered and shipped in release 2.2.5 as an optional { logger, logHistory } argument. An older request, #177 (https://github.com/forge-sql-orm/forge-sql-orm/issues/177), was answered in 3 days. Accepted enhancements are recorded in the CHANGELOG (https://github.com/forge-sql-orm/forge-sql-orm/blob/master/CHANGELOG.md).

Reports and responses are kept in GitHub Issues (https://github.com/forge-sql-orm/forge-sql-orm/issues) and GitHub Discussions (https://github.com/forge-sql-orm/forge-sql-orm/discussions). Both are public, searchable, and every issue and discussion has its own permanent URL.

SECURITY.md (https://github.com/forge-sql-orm/forge-sql-orm/blob/master/SECURITY.md) explains how to report vulnerabilities, which versions are supported and what I commit to do.

SECURITY.md asks reporters to send vulnerabilities to me by private email and not to use public GitHub issues. GitHub private vulnerability reporting is also enabled for the repository (Security tab, "Report a vulnerability").
https://github.com/forge-sql-orm/forge-sql-orm/blob/master/SECURITY.md

No vulnerability reports have been received in the last 6 months, so there is no response time to measure. SECURITY.md (https://github.com/forge-sql-orm/forge-sql-orm/blob/master/SECURITY.md) commits me to acknowledge any report within 48 hours.

The software is built from source with a single command, npm run build (TypeScript compiler producing CommonJS and ESM output in dist/). forge-sql-orm-extra and forge-sql-orm-cli each have their own npm run build (the CLI uses Vite). The build is run automatically in CI (https://github.com/forge-sql-orm/forge-sql-orm/blob/master/.github/workflows/node.js.yml) and the steps are described in CONTRIBUTING.md (https://github.com/forge-sql-orm/forge-sql-orm/blob/master/CONTRIBUTING.md).

The project uses standard JavaScript tooling: npm scripts, the TypeScript compiler (tsc) and Vite for the CLI package.

All build tools (Node.js, npm, TypeScript, Vite) are FLOSS, and the project can be built with only these tools.

The project has an automated test suite written with Vitest (FLOSS, MIT) and released in the same public repository: 37 test files for the core package in tests/, plus 8 for forge-sql-orm-extra and 7 for forge-sql-orm-cli. How to run it is documented in CONTRIBUTING.md (https://github.com/forge-sql-orm/forge-sql-orm/blob/master/CONTRIBUTING.md, "Pre-commit Requirements") and the tests run automatically in CI (.github/workflows/node.js.yml).

The tests are invoked in the standard npm way: npm run test (or npm run test:coverage for coverage) in the repository root and in each package (forge-sql-orm-extra and forge-sql-orm-cli).

Coverage is measured with Vitest (v8 provider) and enforced in CI: each of the three packages (core, forge-sql-orm-extra, forge-sql-orm-cli) has thresholds of 80% for statements, branches, functions and lines, and the build fails if coverage drops below them. Coverage is also reported to SonarCloud, Codacy and Qlty.

Tests for new functionality are required by policy. CONTRIBUTING.md (https://github.com/forge-sql-orm/forge-sql-orm/blob/master/CONTRIBUTING.md) states that any new logic must include corresponding unit tests, and the pull request template (.github/PULL_REQUEST_TEMPLATE.md) has a checklist item "I have added tests that prove my fix is effective or that my feature works". In addition, CI enforces coverage thresholds of 80% in each package, so a change without tests fails the build.

Recent major changes were accompanied by tests. The 2.2.0 modular split added tests for the new forge-sql-orm-extra package (for example resolveForgeSqlOrmOptionsExtra with comprehensive defaults, and unit tests for the ForgeSQLORM public API delegation methods). The new { logger, logHistory } options of applySchemaMigrations (release 2.2.5, #2768) are covered in tests/src/webtriggers/applyMigrationsWebTrigger.test.ts, and the select result ordering fix changed tests/src/utils/forgeDriver.test.ts together with src/utils/forgeDriver.ts. The test suite has 52 test files across the three packages.

The policy is documented in the instructions for change proposals: CONTRIBUTING.md says that any new logic must include unit tests and describes the coverage thresholds, and the pull request template asks contributors to confirm that they added tests.

The project uses ESLint with typescript-eslint (npm run lint, configured in eslint.config.mjs) and TypeScript strict mode ("strict": true and noImplicitAny in tsconfig.json). Knip (npm run knip, knip.config.ts) additionally reports unused and unlisted dependencies, unresolved imports, duplicates and unused enum members as errors, and Prettier (npm run format:check) enforces a consistent code style. All of them run in CI on every pull request and in a husky pre-commit hook.

I enable warnings as strictly as practical. TypeScript runs in strict mode in all three packages; ESLint (typescript-eslint) has no-explicit-any, no-console, unused variables and undefined identifiers at error level on top of the recommended rule set; Knip reports unused dependencies and exports of the dependency graph as errors; and Prettier format checks run in CI. A husky pre-commit hook runs lint-staged, the build, Knip and lint before every commit. On top of that, every pull request goes through SonarCloud with a strict Quality Gate (the Security Rating on new code must be A), Codacy, DeepScan, Qlty (function complexity threshold 8, see qlty.toml), CodeQL and the AI reviewer CodeRabbit. A few Sonar rules are suppressed explicitly in sonar-project.properties, so the exceptions are visible in the repository.

npm run lint currently reports no errors and no warnings, and CI fails on lint errors, so findings are fixed before merging. The few intentional exceptions are marked in the source with explicit eslint-disable comments (mainly no-console for deliberate logging, and no-explicit-any at Drizzle ORM type boundaries). Findings from the other analyzers are fixed as well: Codacy and DeepScan are required checks for merging, SonarCloud findings are fixed before merging (for example rule S8234 in PR #2810), and every pull request is also reviewed by the AI reviewers CodeRabbit and Codacy AI Reviewer, whose comments must be resolved before merging.

I am the primary developer and founder of the project, and I design it following the Saltzer and Schroeder principles. Fail-safe defaults and least privilege: the Rovo integration is deny-by-default and accepts only a single SELECT statement against explicitly configured tables and fields, with optional row-level security; JOINs, subqueries, window functions and data-modifying statements are rejected (forge-sql-orm-extra/src/rovo/Rovo.ts). Complete mediation: all queries go through one driver (src/utils/forgeDriver.ts) that always uses Forge prepared statements with bound parameters. Input validation with allowlists: the Rovo guard validates the statement type, the target table and the selected columns against an allowlist, and date/time values are validated against the range Forge supports. Limited attack surface and economy of mechanism: advanced features (caching, Rovo, SQL parsing) are split out of the core package into the optional forge-sql-orm-extra package, so users who do not need them do not include that code or its dependencies. Open design: security does not depend on hidden implementation details, and the code and documentation are public. I also published a security pattern for connecting Rovo with Forge SQL (https://community.developer.atlassian.com/t/rovo-forge-sql-a-secure-pattern-for-natural-language-analytics-in-forge-apps/97028), later packaged as a reusable guard executor. Vulnerabilities are handled through SECURITY.md.

I know the common errors that lead to vulnerabilities in a database library (OWASP Top 10 and CWE Top 25) and how to counter them. SQL injection (CWE-89): queries are built with Drizzle ORM and executed through Forge prepared statements with bound parameters (src/utils/forgeDriver.ts); for natural-language input from Rovo, the guard accepts only a single validated SELECT on an allowlisted table. Broken access control and missing authorization (CWE-862/639): the Rovo guard supports row-level security, so a user can only read their own rows. Excessive privilege and data exposure: the guard rejects JOINs, subqueries and window functions that could bypass the table and column restrictions. Vulnerable dependencies (CWE-1395): dependencies are updated daily, audited with npm audit, and scanned by CodeQL, SonarCloud, Codacy and DeepScan on every pull request.