You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Proposal: A new option compilerOptions.dependencyTracking
Values:
local -- this is the current behavior
external -- this would check for both local and changes in node_modules and package.json. Transitive dependencies should be accounted for if possible.
π Motivating Example
The motivation is related to #58427, but extends to mono repos.
The current system seems to work well for monolith repos where there is a tsconfig at the root and it coordinates building all the sub-projects. That is not what I am referring to.
I'm talking about a mono repo that is a collection of related workspaces (packages/libraries) that have their own package.json and tsconfig.json files. The package manager controls the order in which workspaces are built, not tsc. tsc is used as part of the build process in an individual workspace. The output directory is always within an individual workspace, because in theory, each of these packages could be published to NPM. Package imports are controlled by package.json#dependencies and exports are listed in package.json#exports. Interdependence between workspaces is generally handled through SymLinks. This is how PNPM and NPM handle it.
Think of a typical morning workflow:
git fetch -- grab all the changes made by my teammates.
git pull --rebase origin/main -- merge in the changes since I'm working on my own branch.
pnpm i -- install any updated packages.
pnpm build -- pnpm will run the build script in each of the workspace based upon the dependency graph (NPM can do the same thing, but you need to define the graph yourself).
At this point, any compile errors should be in my branch, since we keep a clean main branch (always compiles and no errors). If it compiles, then all type checking should be good.
But the current tsc --build . does NOT ensure that the build is correct. It will often miss changes to the .d.ts files in the other workspaces. I was certain this was a bug, see #58427.
If I'm working on WorkspaceA and WorkspaceB by adding a new API interface to WorkspaceB/src/index.ts in WorkspaceB, I would expect the following to pick up the changes in B and work.
Unexpected results and errors can arise by needing to use two different build commands based upon the situation.
Strangely, things magically seem to work if I had been running the following before making changes to WorkspaceB:
repo/WorksapceA $ tsc -b . -w
In summary, I am asking for the option to have tsc --build work a bit harder and check the external dependencies by using an option like compilerOptions.dependencyTracking=external.
Please note: I rarely use the --build option in projects because of this build issue. Some times I am forced to because the only way to make something work is by using composite.
π» Use Cases
What do you want to use this for?
To have the compiler build reliably when there are changes, including external ones.
What shortcomings exist with current approaches?
The current option is to use tsc -b . -f all the time.
What workarounds are you using in the meantime?
Always use force build.
The text was updated successfully, but these errors were encountered:
π Search Terms
build, incremental, composit, tsbuildinfo, location, symlink, stale
β Viability Checklist
β Suggestion
Related to: #58427
Proposal: A new option
compilerOptions.dependencyTracking
Values:
local
-- this is the current behaviorexternal
-- this would check for both local and changes innode_modules
andpackage.json
. Transitive dependencies should be accounted for if possible.π Motivating Example
The motivation is related to #58427, but extends to mono repos.
The current system seems to work well for monolith repos where there is a tsconfig at the root and it coordinates building all the sub-projects. That is not what I am referring to.
I'm talking about a mono repo that is a collection of related workspaces (packages/libraries) that have their own
package.json
andtsconfig.json
files. The package manager controls the order in which workspaces are built, nottsc
.tsc
is used as part of the build process in an individual workspace. The output directory is always within an individual workspace, because in theory, each of these packages could be published to NPM. Package imports are controlled bypackage.json#dependencies
and exports are listed inpackage.json#exports
. Interdependence between workspaces is generally handled through SymLinks. This is how PNPM and NPM handle it.Think of a typical morning workflow:
git fetch
-- grab all the changes made by my teammates.git pull --rebase origin/main
-- merge in the changes since I'm working on my own branch.pnpm i
-- install any updated packages.pnpm build
-- pnpm will run the build script in each of the workspace based upon the dependency graph (NPM can do the same thing, but you need to define the graph yourself).At this point, any compile errors should be in my branch, since we keep a clean main branch (always compiles and no errors). If it compiles, then all type checking should be good.
But the current
tsc --build .
does NOT ensure that the build is correct. It will often miss changes to the.d.ts
files in the other workspaces. I was certain this was a bug, see #58427.Typical inter-workspace workflow:
Given WorkspaceA and depends upon WorkspaceB.
If I'm working on WorkspaceA and WorkspaceB by adding a new API interface to
WorkspaceB/src/index.ts
in WorkspaceB, I would expect the following to pick up the changes in B and work.But it doesn't pick up the change in WorkspaceB.
Instead I have to remember to use:
Unexpected results and errors can arise by needing to use two different build commands based upon the situation.
Strangely, things magically seem to work if I had been running the following before making changes to WorkspaceB:
In summary, I am asking for the option to have
tsc --build
work a bit harder and check the external dependencies by using an option likecompilerOptions.dependencyTracking=external
.Please note: I rarely use the
--build
option in projects because of this build issue. Some times I am forced to because the only way to make something work is by usingcomposite
.π» Use Cases
To have the compiler build reliably when there are changes, including external ones.
The current option is to use
tsc -b . -f
all the time.Always use force build.
The text was updated successfully, but these errors were encountered: