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
Basically you can run into situations where if project A depends on project B, and project B isn't built, you try to resolve to the .ts files and potentially dynamically generate .d.ts files on the fly.
Works pretty well...but what do you do when compiler options differ between the two projects?
We thought "maybe we can just create a different program instance" but then you have to decide whether you show errors?
Feels like skipping errors is the "right" thing to do
How do we handle compile-on-save then? Emit could be wrong if the upstream source is broken.
Is skipping errors the right thing to do? People hate when we don't report errors.
Well, VS Code wouldn't ask anyway.
VS would
What about compiler flags on a per-file basis?
Could imagine you have consistent behavior at production-site, special-case in consumption-sites.
noImplicitAny and noImplicitThis make sense. strictNullChecks might not?
Have to walk up the spine to figure out what the types are when you resolve types.
What are some scenarios you'd want to change between projects?
either to assume those files are part of your project
or try to lazily pull on
or to generate .d.ts files
or to pull on types when they're annotated and not infer from the body.
Maybe we should try to publish some solution to typescript@experimental and see how it works.
What about compile on save?
Either implicitly do it for everyone or force every project to opt in
Probably best to error if some projects and some use it
There's a compilerOnSave in showConfig.
Action items: Ensure that you can at least inherit compileOnSave and give errors if not all projects use it; then in the PR disable errors on external source files, disable emit,
@DanielRosenwasser I've noticed a big drop in the frequency at which these notes are posted. Has there been some internal process change around this? Should we expect to see more or less notes being posted going forward?
The team I work with makes heavy use of TypeScript, and these notes have proven to be a highly valuable insight into the mindset and direction of the TypeScript team. :) It'd be a shame if y'all were unable to continue posting them.
I understand that you're a small team, so no hard feelings if you're unable to continue providing these notes. Just wondering what we should expect going forward! :)
Project References: Using
.ts
/.tsx
when.d.ts
Files Aren't Available#32028
.ts
files and potentially dynamically generate.d.ts
files on the fly.noImplicitAny
andnoImplicitThis
make sense.strictNullChecks
might not?lib
,target
,module
..d.ts
filestypescript@experimental
and see how it works.compilerOnSave
inshowConfig
.compileOnSave
and give errors if not all projects use it; then in the PR disable errors on external source files, disable emit,Array.isArray
,unknown
, andReadonlyArray
#28916
Array.isArray
narrows downnumber | ReadonlyArray<number>
toany[]
!Control Flow Analysis on Element Access Expressions
#31478
The text was updated successfully, but these errors were encountered: