build: standardize tsconfig to Node16 and fix build inconsistencies

[revaarathore11]

Description

The monorepo contained inconsistent TypeScript build configurations across its 10 packages. Some packages used modern Node16 settings while others used legacy esnext settings. This inconsistency led to different output structures in dist/ folders, causing potential import issues and type definition problems for consumers.

Fixes #416

I centralized the TypeScript configuration by introducing a
tsconfig.base.json
that enforces module: Node16 and moduleResolution: node16. This ensures that all packages, regardless of their individual quirks, build with the same rules. I also fixed specific codebase issues (like the /dist/ import path in cloud-registry) that were blocking the build under this standardized configuration

Checklist

• My code follows the contributing guidelines of this project.
• I am aware that all my commits will be squashed into a single commit, using the PR title as the commit message.
• I have performed a self-review of my own code.
• I have commented my code in hard-to-understand areas.
• I have updated the user-facing documentation to describe any new or changed behavior.
• My changes generate no new warnings.
• I have added tests that prove my fix is effective or that my feature works.
• I have not reduced the existing code coverage.

Comments

Summary by Sourcery

Standardize TypeScript configuration across packages using a shared base config and align imports with the new build output structure.

Enhancements:

• Update cloud registry client imports to use the package root providers path instead of dist-specific paths to match the unified build layout.

Build:

• Introduce a root tsconfig.base.json and update all package and template tsconfig.json files to extend it for consistent Node16 compilation settings.

[changeset-bot]

⚠️ No Changeset found

Latest commit: d216a10

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[vercel]

@revaarathore11 is attempting to deploy a commit to the elixir-cloud-aai Team on Vercel.

A member of the Team first needs to authorize it.

[sourcery-ai]

Reviewer's Guide

Centralizes TypeScript configuration across all packages by introducing a shared tsconfig.base.json with Node16 settings, updating package and template tsconfig.json files to extend it, and fixing an import path in the cloud registry client to work with the new build output structure.

File-Level Changes

Change	Details	Files
Standardize package TypeScript configs to extend a shared Node16-based base config.	Replace per-package compilerOptions blocks with an "extends" reference to ../../tsconfig.base.json in each package tsconfig.json. Preserve and explicitly list only include/exclude globs in each package tsconfig.json. Ensure all 10 packages now build against the same module and moduleResolution settings (Node16/node16).	packages/ecc-client-elixir-cloud-registry/tsconfig.json packages/ecc-client-elixir-drs-filer/tsconfig.json packages/ecc-client-elixir-ro-crate/tsconfig.json packages/ecc-client-elixir-trs-filer/tsconfig.json packages/ecc-client-ga4gh-drs/tsconfig.json packages/ecc-client-ga4gh-service-registry/tsconfig.json packages/ecc-client-ga4gh-tes/tsconfig.json packages/ecc-client-ga4gh-trs/tsconfig.json packages/ecc-client-ga4gh-wes/tsconfig.json packages/ecc-utils-design/tsconfig.json
Align tsconfig template with the shared base config while keeping template-specific structure.	Update template tsconfig to extend ../../tsconfig.base.json instead of defining full compilerOptions locally. Override only rootDir in compilerOptions to ./src for the template layout. Retain and simplify include list to just src.	scripts/templates/tsconfig.json
Fix a build-breaking import path to match the new Node16-based output layout.	Update provider import path to consume the service-registry package from its root providers export instead of the built dist/providers path. Ensure imports rely on the package’s public API surface rather than build artifact paths, making it resilient to future build layout changes.	packages/ecc-client-elixir-cloud-registry/src/providers/cr-provider.ts
Introduce a centralized base TypeScript configuration used by all packages.	Add a new tsconfig.base.json at the repo root to define shared compiler options, including Node16 module and resolution settings. Use this base config as the single source of truth for TypeScript compilation behavior across the monorepo.	tsconfig.base.json

Assessment against linked issues

Issue	Objective	Addressed	Explanation
#416	Create a shared base TypeScript configuration and ensure all packages extend it to standardize compiler options and build behavior.	✅
#416	Standardize TypeScript build outputs across packages (consistent dist/ structure, .d.ts generation, and source map behavior).	✅
#416	Verify and configure package.json entries so that type definitions are properly exported for all packages.	❌	The diff shows only tsconfig-related changes and one import path fix; there are no modifications to any package.json files to adjust or verify type definition exports.

Possibly linked issues

• #(unknown): PR adds tsconfig.base.json and makes all packages extend it, directly implementing the requested consistent TS build setup.

---

Tips and commands

Interacting with Sourcery

• Trigger a new review: Comment @sourcery-ai review on the pull request.
• Continue discussions: Reply directly to Sourcery's review comments.
• Generate a GitHub issue from a review comment: Ask Sourcery to create an
  issue from a review comment by replying to it. You can also reply to a
  review comment with @sourcery-ai issue to create an issue from it.
• Generate a pull request title: Write @sourcery-ai anywhere in the pull
  request title to generate a title at any time. You can also comment
  @sourcery-ai title on the pull request to (re-)generate the title at any time.
• Generate a pull request summary: Write @sourcery-ai summary anywhere in
  the pull request body to generate a PR summary at any time exactly where you
  want it. You can also comment @sourcery-ai summary on the pull request to
  (re-)generate the summary at any time.
• Generate reviewer's guide: Comment @sourcery-ai guide on the pull
  request to (re-)generate the reviewer's guide at any time.
• Resolve all Sourcery comments: Comment @sourcery-ai resolve on the
  pull request to resolve all Sourcery comments. Useful if you've already
  addressed all the comments and don't want to see them anymore.
• Dismiss all Sourcery reviews: Comment @sourcery-ai dismiss on the pull
  request to dismiss all existing Sourcery reviews. Especially useful if you
  want to start fresh with a new review - don't forget to comment
  @sourcery-ai review to trigger a new review!

Customizing Your Experience

Access your dashboard to:

• Enable or disable review features such as the Sourcery-generated pull request
  summary, the reviewer's guide, and others.
• Change the review language.
• Add, remove or edit custom review instructions.
• Adjust other review settings.

Getting Help

• Contact our support team for questions or feedback.
• Visit our documentation for detailed guides and information.
• Keep in touch with the Sourcery team by following us on X/Twitter, LinkedIn or GitHub.

[sourcery-ai]

Hey - I've found 1 issue

Prompt for AI Agents

Please address the comments from this code review:

## Individual Comments

### Comment 1
<location> `packages/ecc-client-elixir-cloud-registry/src/providers/cr-provider.ts:14` </location>
<code_context>
   ExternalService,
   Error,
-} from "@elixir-cloud/service-registry/dist/providers";
+} from "@elixir-cloud/service-registry/providers";

 // Re-export base types for use in other modules
</code_context>

<issue_to_address>
**issue (bug_risk):** Switching from a dist deep import to a bare subpath may break resolution if the package doesn’t expose that path via exports.

This change from "@elixir-cloud/service-registry/dist/providers" to "@elixir-cloud/service-registry/providers" is nicer, but only if the package exposes a `./providers` subpath (via `exports` in `package.json` or a compatible on-disk layout). If it isn’t explicitly exported, TS path mapping might succeed while Node/bundlers fail at runtime. Please confirm that `@elixir-cloud/service-registry/providers` is an officially supported entrypoint.
</issue_to_address>

---

Sourcery is free for open source - if you like our reviews please consider sharing them ✨

• X
• Mastodon
• LinkedIn
• Facebook

_{Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.}

[revaarathore11]

@anuragxxd please review