Compiler options from extended tsconfig are being ignored

[gablabelle]

In our monorepo, each package has a tsconfig that extends a shared tsconfig located at the root of the yarn workspace. It seems that the compilerOptions from the extended tsconfig are not being taken into consideration.

For example, I had to add "declarationMap": true, in order to generate sourcemaps for d.ts files even though the option is enabled in tsconfig.settings.json.

{
  "extends": "../../tsconfig.settings.json",
  "compilerOptions": {
    "declarationDir": "dist",
    "emitDeclarationOnly": true,
    "declarationMap": true,
    "rootDir": "src"
  },
  "include": ["src"]
}

https://github.com/Floffah/esbuild-plugin-d.ts/blob/362490fc4bf9e5165e492a77c97d0956d8858b29/src/plugin.ts#L15

Not a big deal I guess, but simply wanted to point this out.

Thanks for that plugin! ;-)

[Floffah]

ah yeah this must have been broken when I switched to using conf.conf.compilerOptions because just passing conf.conf makes it not even read the config at all. to fix this I could check if the extends property is there and create a new object which is a spread of the extended config and the project config to pick it up

thank you for the issue :)

[gablabelle]

Path resolution seems to be problematic in your 1.0.5 release.

In my case, monorepo root is /Users/gabriel.labelle/Developer/workjam/workjam-web-next and extended config is located at /Users/gabriel.labelle/Developer/workjam/workjam-web-next/tsconfig.settings.json

The lib is located /Users/gabriel.labelle/Developer/workjam/workjam-web-next/libs/ui-atoms.

Hope it helps. Does not hesitate if you need more info.

[Floffah]

how are you using esbuild in these projects? the plugin relies on working directories

it resolves the extended by using the tsconfig file it found (typescript does this for the plugin using the process.cwd()) and then the plugin uses the path it found to resolve the extended config from that

maybe its picking up your root config instead of the package config?

would it be handy if i added an option to set the working directory for the plugin to use?

[gablabelle]

It's a monorepo (yarn) like this one:

https://github.com/gablabelle/next-mesh-apollo-monorepo-example

tsconfig in each packages extend the tsconfig at root of the monorepo.

[Floffah]

where is esbuild being run though? I suspect its a problem with that so Ill make it configurable for where it checks

[gablabelle]

It is run in each package folders (packages/*).

[Floffah]

can't think of a valid fix so I've just added an option to override the config path. Please install the package from the repository (esbuild-plugin-d.ts@floffah/esbuild-plugin-d.ts) and add this option and tell me if it works. if this is inconvenient I can continue to look for a fix or if you can think of one feel free to open a pull request

just realised the problem, will make a new release fixing it

[Floffah]

fixed in 1.0.6, properly tested this time and definitely works.

[sachinraja]

Seeing this issue (also with "declarationMap": true) in the root tsconfig.build.json. Seems to only be reading from the package's tsconfig.build.json because it works when I put the option in there.

[Floffah]

Seeing this issue (also with "declarationMap": true) in the root tsconfig.build.json. Seems to only be reading from the package's tsconfig.build.json because it works when I put the option in there.

could you provide a reproducible example so i can understand this better? i have a feeling its a problem with moving to the incremental program/host and may be fixed with the solution to #8

[Floffah]

Seeing this issue (also with "declarationMap": true) in the root tsconfig.build.json. Seems to only be reading from the package's tsconfig.build.json because it works when I put the option in there.

After rereading I have a few ideas as to what this could be

What is the working directory of the process when you run esbuild? If it's the root of the project that'll be the problem as it finds the first one it sees inline with a package.json using a function provided by typescript

[sachinraja]

Sorry for the delay, here's a repro. Issue seems to be that I set declarationDir, removing that fixes it.

[Floffah]

alright ill look into this when i get time thank you!

[verikono]

I had a similar issue adjusting. Resolved by modifying:

{
    "extends": "@tsconfig/vite-react/tsconfig.json",
        .....
}

to

{
    "extends": "./node_modules/@tsconfig/vite-react/tsconfig.json",
        ...
}

[Floffah]

If this wasn't fixed before, it should be now (v1.2.0). I added tests to account for this use case