- 
                Notifications
    You must be signed in to change notification settings 
- Fork 13.1k
Open
Labels
Design NotesNotes from our design meetingsNotes from our design meetings
Description
Rethinking BuiltinIterator and Introducing IteratorObject
- Created two related but separate new features in 5.6
- --strictBuiltinIteratorReturn
- Iterator helper methods, which are installed on BuiltinIterators.
 
- Annoyingly, you always have to write BuiltinIterator<T, BuiltinIteratorReturn>instead of justBuiltinIterator<T>- over and over.- You'd assume it could be the default - but you can't because generators inherit from BuiltinIteratorand they default tovoidas theTReturn.- Not compatible.
 
 
- You'd assume it could be the default - but you can't because generators inherit from 
- What's proposed?
- The type representing values backed by Iterator.prototype- is renamed toIteratorObject<T, TReturn, TNext>.
- BuiltinIteratorstill exists, but now it's now just- BuiltinIterator<T>. It inherits from- IteratorObject<T, BuiltinIteratorReturn, unknown>.
- All methods returning Iterator.prototype-backed iterators still return aBuiltinIterator<T>.
 
- The type representing values backed by 
- Do we need compatibility between the beta and RC?
- No, because things aren't stable yet.
 
- We could also have separate ArrayIterator<T>,MapIterator<T>, andSetIterator<T>types, but that's not in the PR.- Should we?
- It could avoid confusing people trying to decide between IteratorObjectandBuiltinIterator.- Might still need to write an explicit IteratorObject<SomeType, BuiltinIteratorReturn, unknown>in a lot of cases.- DOM types might actually have their own iterator type too. Have to check.
 
 
- Might still need to write an explicit 
- These all have different runtime types, so it might be a good idea. If someone monkey-patches one of these, it shouldn't appear on other iterators.
 
- It could avoid confusing people trying to decide between 
 
- Should we?
- Reminder: what is BuiltinIteratorReturn?- An intrinsictype that represents the return type of aBuiltinIterator. Eitheranyorundefineddepending on--strictBuiltinIteratorReturn(which is under--strict).
- Probably needs a comment in lib.d.ts.
 
- An 
- Should IteratorObjecthave defaults ofunknownforTReturn/TNext?- It would be nice! Iterator<T>doesn't needTReturnandTNext.
- Should TNextactually be something more specific thanunknown?- Possibly fine - it's all about delegation.
 
- Leaning towards doing this.
 
- It would be nice! 
Iterator Helpers for ES5-Emitted Generators
- A way of correctly linking up polyfills of Iterator.prototypewith downleveled generators.
- Does this work with ES6 generators?
- Yes, the iterators themselves exist and you can polyfill the behavior.
 
Refactoring NodeBuilderFlags
- We have too many flags, can't be represented within 32 bits.
- Can try to avoid this by adding another parameter, using an object, possibly a bigint.- Don't waste time on bigint, it will never be efficient.
 
- Why not just parameters?
- Need an overload (it's in the public API and there are arguments that follow it)
- Also: want to avoid flag confusion.
 
- How many public APIs take this?
- Like 10 publicly.
 
- Also, we have a bunch of internal flags that are just for us.
- Maybe start by moving all the internal flags into a separate enum, keep the user-facing ones on the existing public one.
- Can just add internal overloads instead.
 
- People prefer two different enums, will figure out how the overloads should look.
"Fail Fast" Flag For --build (a.k.a. --noDownStreamOnError)
- Previously, as soon as a project had errors under --build, TypeScript would just stop. Wouldn't emit files, wouldn't check other projects.
- In 5.6 this changed. Nice because it allows flexibility when a codebase is in an error state. Upgrades can happen incrementally in other parts of the codebase.
- Kind of annoying in a different way. Going project-by-project from upstream (the roots) to downstream (the leaves) is much harder because TypeScript blindly keeps building every depending project.
- Some of us thought you could opt into the old behavior if you write noEmitOnError- but that's not the case. It would toggle TypeScript not to produce outputs, but it will still continue to check other projects.
 
- Some of us thought you could opt into the old behavior if you write 
- So the PR introduces a flag to "fail fast" on a project error.
- Currently named noDownstreamOnError, but not a fan of making users think about the words "upstream"/"downstream".- What should we name the flag?
- we like --stopBuildOnErrors.
 
- This new flag almost implies the old behavior - but not exactly the same.
- How?
- Previously, a failing project wouldn't produce files and "failed fast" on the entire build. Under this mode, the failing project will still produce files but will fail fast after that.
- [[Note: Possible that --noEmitOnErrorin conjunction with the new flag is basically what you want?]]
 
 
- How?
- Kind of odd that the flag is opt-in. Old behavior might be more desirable by default.
- Should the two flags have some implication of the others?
- Maybe?
 
- We want to revisit to think about the flow here.
tonivj5 and mon-jaitonivj5
Metadata
Metadata
Assignees
Labels
Design NotesNotes from our design meetingsNotes from our design meetings