- 
                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 justBuiltinIterator<T>. It inherits fromIteratorObject<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