Closed
Description
Declare const enum
s as Non-const
in Declaration Files
const enum
s are supposed to be inlined, butisolatedModules
issues an error because some compilers can't resolve across modules.- We also have
preserveConstEnum
s - means you have a runtime representation, the compiler will inline the values, but downstream consumers technically can grab the values from runtime values. - Can be frustrating - inline is nice for libraries, but not for consumers because late binding (deferred resolution) is occasionally necessary across modules.
- Idea was what if these flags changed the declaration file output?
- Has issues for some "consumers" which are really the original authors. Separate compilations should be able to opt in to whatever they want.
- Which flag modifis the behavior?
isolatedModules
orpreserveConstEnum
? - Another idea:
preserve
modifier. - Why is
preserveConstEnum
even a flag?- Version drift of the compiler, people would get enums with shifted versions when upgrading TypeScript slightly.
isolatedModules
on a dependent project shouldn't have any bearing how a dependency should interpret thing.- Why do we have
const enum
s again?- Huge performance gain thanks to just inlining the values.
- Before modules and
const
existed. - Maybe JITs are better with
const
? - TDZ issues - not always easy, unclear if that's guaranteeed to be fast.
- Only safe to inline when everything is "part of the same build process".
- Whatever that means.
- A
preserved
keyword could ask "is this part of a project reference" and do the right thing? - Hate the idea of another modifier though. This is really hard to explain.
- Seems like there should be an inlining step from a "sufficiently smart bundler"™️
- Reminds us of
internal
- who is a declaration internal to? Module? Project? Package? Monorepo/solution? Something else?- Maybe API Extractor gets to choose this.
- Conclusion: not totally sold on the PR because we want to avoid adding more to
const enum
s.
Partial
Adds | undefined
to Index Signatures in exactOptionalProperties
- Generally speaking, when you apply
Partial
to a property, we add themissing
type to the property. - What about index signatures?
- Index signatures inherently are optional, so you can't mark them as optional.
- All that would do for you is say whether or not you get
undefined
implicitly.
- Could imagine it though - an index signature that implicitly reads
undefined
, but doesn't allow writes of it. noUncheckedIndexAccess
automatically adds theundefined
.- So should we allow
?
on index signatures?- Kind of acts as a way to migrate yourself onto
noUncheckedIndexAccess
. - But only if you're in
exactOptionalProperties
mode. - Otherwise, it just implicitly adds
undefined
to the index signature.
- Kind of acts as a way to migrate yourself onto
- When a mapped type adds a
?
, we add a regularundefined
to the type, regardless ofexactOptionalProperties
. - If we were using
exactOptionalProperties
, we would probably use this in a few places. - Conclusion: feels like it can be valuable.
JSX Attribute Changes
Notes from @andrewbranch
(<div foo="hello"></div>)
Some people want to use template strings for everything, but the JSX spec doesn't currently allow it.
(<div foo=`hello`></div>)
Also proposing reinterpreting the character values of a string from the ECMA262 spec to the WHATWG spec for HTML attributes, meaning:
(<div foo=" "></div>)
would be interpreted differently.
- We would probably have to encode these string values as HTML internally
- Should we provide feedback to Facebook on this?
-
There's a consistency problem:
(<div title="‐">hello</div>)
In HTML, this is a tooltip with text
-
. In JSX, it's currently a tooltip with text‐
.
Changing it would introduce a refactoring hazard if you change to:(<div title={"‐"}>hello</div>)
-
React could do this during rendering instead of the JSX transformer doing it; that would still be a big breaking change.
-
- Conclusion: We don't have many details on this - need to follow up and clarify that we're understanding the proposal