fix: get tsconfig in each pkg for monorepos

[RikoRodriges]

Added support for retrieving individual tsconfig.json files for each package within the monorepo. Previously, a single tsconfig.json file was applied from the invoking package, resulting in a unified rule for aliases across all packages. Now, each package can use its own tsconfig.json with unique aliases, allowing for more flexible build configurations per package

[acrazing]

The tsconfig.json may not exists. If you want to do that, you may need to findTsconfigDir rather than findPackageRoot.

[RikoRodriges]

If tsconfig.json does not exist readConfigFile will return:

{
  config: {},
  error: {
    messageText: 'Cannot read file'
  }
}

In this case, the code will not break, and the module will still be parsed.

---

If you think this is not a good approach, we can pass tsconfig.json by specifying the root directory from the current working directory (where dpdm is run).

[acrazing]

It will skip the existing tsconfig in root directory if there is a sub directory has package.json.

[RikoRodriges]

Thank you for your feedback. I have taken your comments into account and updated the PR accordingly to ensure the root tsconfig is not skipped when there is a package.json in a subdirectory. Please let me know if there are any additional adjustments you'd like me to make.

[acrazing]

Please review the comments.

[RikoRodriges]

@acrazing ping

[acrazing]

Thanks a lot for the PR and for the patience here. I agree the underlying use case is real: monorepos can have subprojects with different path aliases, and dpdm should eventually have a better story for that.

I’m going to close this PR for now, though, because finding the correct tsconfig.json is not quite as simple as walking to the nearest package root. TypeScript itself does not switch configs per imported file in a single project; for subprojects it usually relies on project references or an explicit build/config graph. For dpdm, I think we need a configuration model similar to references so we can resolve subprojects intentionally instead of guessing from package.json locations.

That probably belongs after the config-file feature lands, since this needs user-provided project structure rather than implicit discovery only.

In the meantime, I suspect many cases can still be handled with a single root tsconfig.json. If your project cannot be represented that way, please feel free to share the concrete layout and aliases here. I’m happy to help figure out a working setup or use it to guide the future config design.