List of keywords you searched for before creating this issue. Write them down here so that others can find this suggestion more easily and help provide feedback.
✅ Viability Checklist
My suggestion meets these guidelines:
[ x] This wouldn't be a breaking change in existing TypeScript/JavaScript code
[ x] This wouldn't change the runtime behavior of existing JavaScript code
[ x] This could be implemented without emitting different JS based on the types of the expressions
[ x] This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)
{
"compilerOptions": {
"target": "es2016", /* Set the JavaScript language version for emitted JavaScript and include compatible library declarations. */
"module": "commonjs", /* Specify what module code is generated. */
"esModuleInterop": true, /* Emit additional JavaScript to ease support for importing CommonJS modules. This enables `allowSyntheticDefaultImports` for type compatibility. */
"forceConsistentCasingInFileNames": true, /* Ensure that casing is correct in imports. */
"strict": true, /* Enable all strict type-checking options. */
"skipLibCheck": false,
"declaration": true,
"baseUrl": "./",
"paths":{
"xyz-a":["xyz-a"],
}
},
"watchOptions": {
"excludeDirectories": ["**/node_modules"]
}
}
Suppose xyz-a/src/index.ts is changed to
xyz-a/index.ts
export {hello as foobar} from "./hello"
Currently with a top level
npx tsc -b -w
that will cause xzy-a to be rebuilt but
the change in xyz-a/dist/src/index.d.ts
does not trigger an rebuild/recheck of xyz-b
Example 2
Similar initial situation as Example 1 but suppose a separate build step from a non-Typescript tool,
in a manner opaque to Typescript,
creates an output from xyz-a to serve as an input to xyz-b.
Any solution ought to work for this case too.
(Two birds one stone.)
Therefore "pushing" xyz-a's change to xyz-b without a file watch
would probably not be a good solution.
(Above example as a working project available on demand.)
💻 Use Cases
Currently these changes aren't propagated and requires a forced rebuild to detect any errors resulting from the change.
Hier. "tsc -b -w" build - Allow option for change in dependency ".t.ds" file to trigger recheck/rebuild in depender
🔍 Search Terms
hierarchical dependencies watch build dependencies
List of keywords you searched for before creating this issue. Write them down here so that others can find this suggestion more easily and help provide feedback.
✅ Viability Checklist
My suggestion meets these guidelines:
⭐ Suggestion
In a hierarchical "tsc -b -w" build, allow option for change in dependency ".t.ds" file to trigger recheck/rebuild in depender.
📃 Motivating Example
Example 1
xyz-a/hello.ts
xyz-a/index.ts
xyz-b/call.ts
Top level configuration
tsconfig.json
tsconfig.options.json
Suppose
xyz-a/src/index.ts
is changed toxyz-a/index.ts
Currently with a top level
that will cause
xzy-a
to be rebuilt but the change inxyz-a/dist/src/index.d.ts
does not trigger an rebuild/recheck ofxyz-b
Example 2
Similar initial situation as Example 1 but suppose a separate build step from a non-Typescript tool, in a manner opaque to Typescript, creates an output from
xyz-a
to serve as an input toxyz-b
.Any solution ought to work for this case too. (Two birds one stone.) Therefore "pushing"
xyz-a
's change toxyz-b
without a file watch would probably not be a good solution.(Above example as a working project available on demand.)
💻 Use Cases
Currently these changes aren't propagated and requires a forced rebuild to detect any errors resulting from the change.