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
If you parenthesize the right side of the extends clause in a conditional type, it changes distributivity.
Tools like Prettier assume parentheses are purely stylistic unless it's meant to enforce precedence. They will remove them, which can change the meaning.
Claimed this was intentional; however, our docs only mention using [] to avoid distributivity.
Bracketing just falls out of the general rules of "distributivity only happens on naked type variables".
We added an optimization for [], but parentheses were affected.
That seems unrelated!
Can we just get a more minimal repro?
Hard to get, need to work on this.
Let's recategorize as a bug, discuss further to ensure we're all on the same page.
How does this work with merging? Multiple declarations? Fallbacks?
Maybe there needs to be a lookup strategy.
// globals.d.ts// No import attributesdeclare module "*.css"{declareconst_default: CSSStyleSheet;exportdefault_default;}// ...// Some modules// Has import attributesimportstylesfrom"./styles.css"with{type: "css"};
Why can't you get away with just always using a *.css pattern?
Bundlers and browsers decide on different behavior - or rather, bundlers decide differently.
Stepping back, pattern ambient modules really mask over everything. Kind of heavy-handed. You do want TypeScript to resolve the .css file on disk and validate that it's there, right? Usually?
Want to express "what is my bundler going to do here?", and sometimes it is not best-served by what's in an ambient module, but rather what's on disk.
You can express that with .d.css.ts files under some settings.
Parentheses Changes Result of Conditional Type
#56270
#56271
extends
clause in a conditional type, it changes distributivity.[]
to avoid distributivity.[]
, but parentheses were affected.Ambient module declarations for import assertions
#46135
Browsers have either shipped or indicate positive support for this feature.
What is it? Basically want to be able to import assets like
css
files and bring them in as default imports in the form ofCSSStyleSheet
objects.How do you convince TypeScript of this?
Maybe something like:
How does this work with merging? Multiple declarations? Fallbacks?
Maybe there needs to be a lookup strategy.
In other words, do
and
both resolve to the following declaration?
Why can't you get away with just always using a
*.css
pattern?Stepping back, pattern ambient modules really mask over everything. Kind of heavy-handed. You do want TypeScript to resolve the
.css
file on disk and validate that it's there, right? Usually?Want to express "what is my bundler going to do here?", and sometimes it is not best-served by what's in an ambient module, but rather what's on disk.
.d.css.ts
files under some settings.What about something like
*.css
imports, but does provide a well-understood shape.Doesn't this need a special resolution mode?
How does this affect emit?
.json
files..css
files from source?.d.css.ts
generation?How do
.json
imports work at all today?Wait, we do copy JSON to outputs?
outDir
.We do want a bit more context on how this should work in a larger project.
Conclusions?
Revisit real resolution/emit for certain file types, plus import attribute-y ambient modules
Want to understand the full breadth of motivations
The text was updated successfully, but these errors were encountered: