mirror of
https://github.com/Frooodle/Stirling-PDF.git
synced 2026-03-04 02:20:19 +01:00
1cc562a6b1
# Description of Changes This PR fixes false-positive TypeScript errors in our layered build setup (core → proprietary → desktop) by ensuring each build’s typecheck only evaluates files that are actually part of that build’s reachable module graph. This prevents overridden core implementations from being typechecked in higher-layer builds where they are effectively unreachable due to alias-based overrides. ## Background We maintain multiple build targets from a layered source tree: - core: open source baseline - proprietary: core + proprietary additions/overrides - desktop: proprietary + desktop-specific additions/overrides We implement overrides via paths/aliases such that placing a file in a higher layer at the same relative path supersedes the lower-layer file at runtime. For safety, we run TypeScript typechecking independently per build target to ensure all builds remain valid. ## Problem Our existing tsconfig setup often typechecked files that are not actually reachable in a given build. Specifically: - When a file in core is overridden by a file in proprietary or desktop, the overridden core file can still be included in the TypeScript Program for the higher-layer build (typically due to broad include globs). - This produces false-positive type errors in higher-layer typecheck runs, even though those core files are effectively unreachable in the build. This created friction and noise, and meant we had to make unnecessary changes to `core` to make the other builds happy, reducing type safety in the process. ## Solution This PR adjusts the tsconfig strategy so each build target's typecheck is driven by reachable entrypoints rather than blanket inclusion of all layer source trees. Concretely: - Each build’s tsconfig now includes only: - that build’s entrypoints and layer sources that are intended to be compiled for the target - any shared/top-level sources required by the target - Lower layers (e.g., core) are not globally included in higher-layer builds; they are instead pulled in through module resolution only when actually referenced (with paths ordering ensuring the correct override wins). - This means that we still check all the files that will actually be run with whatever the overridden logic is, but avoid wasting time and introducing false-positives by not checking files which have been overridden. ## Notes Unfortunately, the config we use for the type checking can't be the same as the one we use for Vite in this strategy. Vite needs to know about the entire source tree, so it can't only include the subfolders because it causes build errors. Because of this, I've duplicated the existing (valid) tsconfig files and use them for Vite. This is a little clunky but it does the job. Some day hopefully I'll come back to it and be able to figure out a nicer way to do it, but for now at least, this solves the type checking issues without impacting the runtime builds. Also, I noticed that `@desktop` is defined as an alias, which was presumably missed when I was removing the self-aliases from the files. I don't see why you'd ever need to have a desktop file reference `@desktop` to say "import this but make it impossible for something else to override the import". I've removed the `@desktop` alias in this PR while I was in there.
Stirling PDF - The Open-Source PDF Platform
Stirling PDF is a powerful, open-source PDF editing platform. Run it as a personal desktop app, in the browser, or deploy it on your own servers with a private API. Edit, sign, redact, convert, and automate PDFs without sending documents to external services.
Key Capabilities
- Everywhere you work - Desktop client, browser UI, and self-hosted server with a private API.
- 50+ PDF tools - Edit, merge, split, sign, redact, convert, OCR, compress, and more.
- Automation & workflows - No-code pipelines direct in UI with APIs to process millions of PDFs.
- Enterprise‑grade - SSO, auditing, and flexible on‑prem deployments.
- Developer platform - REST APIs available for nearly all tools to integrate into your existing systems.
- Global UI - Interface available in 40+ languages.
For a full feature list, see the docs: https://docs.stirlingpdf.com
Quick Start
docker run -p 8080:8080 docker.stirlingpdf.com/stirlingtools/stirling-pdf
Then open: http://localhost:8080
For full installation options (including desktop and Kubernetes), see our Documentation Guide.
Resources
Support
- Community Discord
- Bug Reports: Github issues
Contributing
We welcome contributions! Please see CONTRIBUTING.md for guidelines.
For development setup, see the Developer Guide.
For adding translations, see the Translation Guide.
License
Stirling PDF is open-core. See LICENSE for details.