Visitor throws `Cannot read property 'kind' of undefined` using TypeScript@3.9.2

[lukaskl]

TypeScript Version:

• 🔴3.9.2
• 🔴3.9.1-rc
• 🔴3.9.0-beta
• ✅3.8.3 (it work with previous versions)

Search Terms:
Visitor TypeError kind undefined 85032

Code

Unknown (Error is thrown at node_modules/typescript/lib/typescript.js:85032:35)

But this part triggers it

export interface ColorProps {
 style?: CSSProperties
}

const Color = styled(({ style }: ColorProps) => (
 <div
 style={{
 ...style,
 background: `anything`,
 }}
 />
))``

Expected behavior:

It compiles

Actual behavior:

 TypeError: Cannot read property 'kind' of undefined

 at visitObjectLiteralExpression (node_modules/typescript/lib/typescript.js:85032:35)
 at visitJavaScript (node_modules/typescript/lib/typescript.js:83441:28)
 at visitor (node_modules/typescript/lib/typescript.js:83384:24)
 at visitNode (node_modules/typescript/lib/typescript.js:74768:23)
 at Object.visitEachChild (node_modules/typescript/lib/typescript.js:75209:108)
 at visitJavaScript (node_modules/typescript/lib/typescript.js:83491:31)
 at visitor (node_modules/typescript/lib/typescript.js:83384:24)
 at visitNodes (node_modules/typescript/lib/typescript.js:74819:48)
 at Object.visitEachChild (node_modules/typescript/lib/typescript.js:75034:53)
 at visitObjectLiteralExpression (node_modules/typescript/lib/typescript.js:85057:23)

Playground Link:

• minimal reproducible repository - https://github.com/lukaskl/typescript-visitor-bug-report

Related Issues:

• TypeError: Cannot read property 'kind' of undefined #38383, this report could be duplicate of TypeError: Cannot read property 'kind' of undefined #38383, however, the error message is really a generic one and this error is thrown at a completely different place - therefore, for me it seems like a different issue (sorry in advance if this will turn out as a duplicate 👀).

[lissein]

I managed to reduce the reproduction code down to:

const f = (props: any) => (...args: any) => ''; 

f({
 background: `${1} anything`,
 ...{ test: 1 },
})``

The issue is in the es2015 transformer so any target above es2015 will be fine. In fact, the issue is in the object literal visitor when the node contains "es2015 features (eg. template literals, arrow functions, ...)" that need to be transformed. So you can reproduce the same crash with this code using arrow functions:

const f = (props: any) => (...args: any) => ''; 

f({
 background: (() => 1)(),
 ...{ test: 1 },
})``

This code, for instance does not crash because the object literal doesn't have any es2015 features in it.

const f = (props: any) => (...args: any) => ''; 

f({
 background: 'anything',
 ...{ test: 1 },
})``

I'll try to fix this.

---

Until the bug is fixed, Lukas Klusis (@lukaskl) you can use a string instead of a template literal for the background variable or use an external variable to store the template literal outside of the object literal like that:

export interface ColorProps {
 style?: CSSProperties
}

const Color = styled(({ style }: ColorProps) => {
 const background = `${1 + 1}`;
 return (
 <div
 style={{
 ...style,
 background,
 }}
 />
 );
})``

[lukaskl]

Thank you Lissein (@lissein) for investigating this!

To add another workaround, it is also possible to split this into two definitions, e.g.:

const ColorUnstyled = ({ style }: ColorProps) => (
 <div
 style={{
 ...style,
 background: `anything`,
 }}
 />
)

const Color = styled(ColorUnstyled)``

[lissein]

After more investigations, I confirmed that the code crashing is in the es2015 transformer but the root cause is not in here. The bug is actually in the es2018 transformer.
Here is an example of code with a target es2017 (< es2018):

const f = (props: any) => (...args: any) => ''; 

f({
 background: (() => 1)(),
 ...{ test: 1 },
})``

const a = {
 ...{ test: 1 },
}

"use strict";
const f = (props) => (...args) => '';
f({
 background: (() => 1)(),
 ...{ test: 1 },
}) ``;
const a = Object.assign({ test: 1 });

As you can see, the second spread is transpiled correctly but the first one isn't.

[elibarzilay]

(This is most likely very unrelated to #38383...)