Definitelytyped: [@types/styled-components] 编译器的性能问题

创建于 2019-04-02  ·  37评论  ·  资料来源: DefinitelyTyped/DefinitelyTyped

通过使用最新的[email protected] ，将最新版本的 @types/styled-components 添加到现有项目会导致构建时间增加大约 1-2 分钟

通过使用这个种子仓库，我测试了以下版本：

w/o     2.3s
4.0.0   5.6s
4.1.0   8.0s
4.1.5   8.0s
4.1.10  10.1s
4.1.11  90.1s
4.1.12  97.1s

我的机器是 Linux 4.18.0 (Ubuntu 18.10) 笔记本电脑，带有 i7-6700HQ CPU @ 2.60GHz

很明显，4.1.11 版是导致此性能问题的原因。 此版本的 PR 是 #33061。 至于为什么，我真的不知道——我试图深入研究编译器的内部结构，看看它卡在哪里，但我无法理解。

  • [x] 我尝试使用@types/xxxx包，但遇到了问题。
  • [x] 我尝试使用最新的稳定版 tsc。 https://www.npmjs.com/package/typescript
  • [x] 我有一个不适合StackOverflow 的问题。 （请在那里提出任何适当的问题）。
  • [x] [提及](https://github.com/blog/821-mention-somebody-they-re-notified) 作者（见Definitions by:中的index.d.ts ）所以他们可以回应。

    • 作者： @eps1lon @Igorbek @Jessidhia

picture voliva
👍35

最有用的评论

@RyanCavanaugh重新开放？

picture fabb 于 2020-07-16
👍15

所有37条评论

打字稿3.3也会发生这种情况吗？

eps1lon picture eps1lon 于 2019-04-03

我遇到了同样的问题

包.json

开发依赖

"@babel/core": "^7.4.0",
"@babel/plugin-proposal-class-properties": "^7.4.0",
"@babel/plugin-syntax-dynamic-import": "^7.2.0",
"@babel/plugin-transform-async-to-generator": "^7.4.0",
"@babel/preset-env": "^7.4.2",
"@babel/preset-react": "^7.0.0",
"@babel/preset-typescript": "^7.3.3",
"babel-jest": "^24.5.0",
"babel-loader": "^8.0.5",
"babel-plugin-styled-components": "^1.10.0",
"css-loader": "^2.1.1",
"file-loader": "^3.0.1",
"html-webpack-plugin": "^3.2.0",
"jest": "^24.5.0",
"mini-css-extract-plugin": "^0.5.0",
"node-sass": "^4.11.0",
"react-svg-loader": "^2.1.0",
"regenerator-runtime": "^0.13.2",
"sass-loader": "^7.1.0",
"style-loader": "^0.23.1",
"ts-loader": "^5.3.3",
"typescript-tslint-plugin": "^0.3.1",
"webpack": "^4.29.6",
"webpack-cli": "^3.3.0",
"webpack-dev-server": "^3.2.1"

依赖

"@babel/polyfill": "^7.4.0",
"@loadable/component": "^5.7.0",
"@types/loadable__component": "^5.6.0",
"@types/react": "^16.8.10",
"@types/react-dom": "^16.8.3",
"@types/react-router-dom": "^4.3.1",
"@types/styled-components": "4.1.5",
"axios": "^0.18.0",
"react": "^16.8.6",
"react-dom": "^16.8.6",
"react-router": "^5.0.0",
"react-router-dom": "^5.0.0",
"styled-components": "^4.2.0",
"styled-normalize": "^8.0.6",
"typescript": "^3.4.1"

我的问题是看起来 webpack 和 webpack-dev-server 无法解析 @types/styled-components。 因为当只使用样式组件时，没有问题。 同时使用@types/ [email protected]时总是会发生这种情况。

在看到@voliva 的问题之前，我发现了

将@types/styled-compoents 版本改为4.1.5 后，看起来一切正常。

DylanJu picture DylanJu 于 2019-04-03
👍4

@eps1lon ：不， 3.4.0-dev.20190226 版本。

使用@voliva的种子存储库，我相信我已经将问题定位到OmitU的递归用法，添加在 @types/styled-components 4.1.1 版中。 这是它的定义：

type OmitU<T, K extends keyof T> = T extends any ? PickU<T, Exclude<keyof T, K>> : never;

这里既是地方的OmitU在使用index.d.ts ：

WithOptionalTheme

type WithOptionalTheme<P extends { theme?: T }, T> = OmitU<P, "theme"> & {
    theme?: T;
};

WithOptionalTheme用法（在StyledComponentProps的定义中）

WithOptionalTheme<
    OmitU<
        ReactDefaultizedProps<
            C,
            React.ComponentPropsWithRef<C>
        > & O,
        A
    > & Partial<PickU<React.ComponentPropsWithRef<C> & O, A>>,
    T
>

联合分布的OmitU映射到另一个OmitU似乎会绊倒编译器。 如果这些实例中的一个或两个被替换为不分布在联合上的常规Omit ，则在 typescript 3.4.1 下，编译时间将减少到合理的 10 秒左右。

（请注意， ReactDefaultizedProps类型还引用了PickU ，这可能有助于解释下表第二行中特别长的运行时间。）

为了测试这一点，我用以下之一替换了分布式OmitU的一个或两个：

type OmitPickU<T, K extends keyof T> = PickU<T, Exclude<keyof T, K>>;
type Omit<T, K extends keyof T> = Pick<T, Exclude<keyof T, K>>;

这是针对打字稿3.4.1 、 3.4.0-dev.2019 0226和前一个版本 3.4.0-dev.2019 0223运行的time yarn tsc ：

| WithOptionalTheme定义 | WithOptionalTheme用法 | 打字稿 3.4.1 | 打字稿 3.4.0-dev.20190226 | 打字稿 3.4.0-dev.20190223 |
| --- | --- | --- | --- | --- |
| OmitU | OmitU | 1m28.984s | 0m55.853s | 0m6.031s |
| OmitU | OmitPickU | 2m49.492s | 1m49.457s | 0m5.961s |
| OmitPickU | OmitU | 1m10.313s | 0m35.278s | 0m6.125s |
| OmitPickU | OmitPickU | 0m10.501s | 0m6.947s | 0m6.055s |
| OmitU | Omit | 0m9.611s | 0m6.781s | 0m6.102s |
| Omit | OmitU | 0m10.471s | 0m7.451s | ...等|
| OmitPickU | Omit | 0m9.654s | 0m6.796s | |
| Omit | OmitPickU | 0m8.990s | 0m6.485s | |
| Omit | Omit | 0m9.730s | 0m6.815s | |

typescript 3.3.3和3.3.4000 的运行时间与 3.4.0-dev.20190223 一致——大约 6 秒。

我对样式组件不够熟悉，无法提出解决方案，但我希望这些数据有帮助！

michsa picture michsa 于 2019-04-03
👍4

我可以确认我有同样的问题。 将@types/styled-components 降级到 4.1.5 也对我有用。 我在打字稿 3.4.1

flut1 picture flut1 于 2019-04-03
👍5 🎉1

@michsa我期待一些减少，但不是 10 倍。 由于这是在 typescript 3.4 中引入的，您是否也可以在 typescript repo 中打开一个问题？ 如果它是应该在打字稿中修复的回归，我想确保我们不会恢复错误修复。

eps1lon picture eps1lon 于 2019-04-03

抱歉，我最初没有在 typescript 的 github 中搜索，我发现他们目前正在调查这个问题： https :

voliva picture voliva 于 2019-04-03
👍4

@weswigham @RyanCavanaugh我们能否快速发布一个恢复到在 3.4 上没有性能问题的样式组件类型。

随着 VS Code 1.33 的发布，很多 js 用户将通过自动类型获取来下载被窃听的类型。 一旦发生这种情况，要摆脱糟糕的状态，我相信您要么必须清除自动类型获取缓存，要么安装固定的@types/styled-components 。 对于 js 用户来说也不是很好的体验。 最新发布的版本表现不佳的打字时间越长，受影响的用户就越多（这对他们来说是一种糟糕的体验，对我们来说也有很​​多额外的工作）

mjbvz picture mjbvz 于 2019-04-05
👍8

这似乎仍然是@types/styled-components 4.1.19 和 TS 3.6.3 的问题。 TS 完成和错误突出显示在 2018 i7 macbook pro 15 上需要 5-10+ 秒。需要做更多调查。

AndrewMorsillo picture AndrewMorsillo 于 2019-09-11
👍1

嗯，OP 正在谈论 90 年代的编译（时间比之前的样式组件版本快 9 倍），因为 TS 的更高版本都有缓解措施，并且样式组件的更高版本被简化为没有那么多的性能问题，5-10s 可能只是你的项目和 deps 表现正常。

weswigham picture weswigham 于 2019-09-11
👎1

我希望不是！ 当它不是过去时，它现在慢得令人沮丧。 如果它似乎与此问题有关，我将进一步研究它并在此处报告。

AndrewMorsillo picture AndrewMorsillo 于 2019-09-12
👍1

我添加@types/styled-components 后，我的 VSCde 就无法使用（ts 错误在几秒钟后出现并消失，而不是立即消失）。

我正在使用 TS 3.6.4 和类型 4.1.20。

sregg picture sregg 于 2019-11-01
👍1

@sregg去责怪这个 PR 在@types/styled-components中恢复了缓解： https :

weswigham picture weswigham 于 2019-11-01
👍1

（并回滚到 v 4.1.19以在本地解决问题）

weswigham picture weswigham 于 2019-11-01
👍1

@sregg去责怪这个 PR 在@types/styled-components中恢复了缓解措施：#39323

@typescript-bot 收集性能指标以“衡量 [PR] 是否可能对编译时间或编辑器响应能力产生负面影响”。 在 PR 39323 中，@typescript-bot 得出结论： “看起来没有太大变化。” .

@sregg ，您能想出为什么@typescript-bot 的现有指标无法突出您观察到的编辑器性能问题的原因吗？

（边栏： “去责怪这个 PR”不是一个建设性的建议，@weswigham。请建设性。）

smockle picture smockle 于 2019-11-02

这是一些额外的上下文：

@sregg在使用 TypeScript 3.6.4 时报告性能不佳： https :

但是从@weswigham 在https://github.com/microsoft/TypeScript/issues/30663#issuecomment -507406245 中的回复中，我了解到 TypeScript 版本 ≥3.5 将不再导致https://github.com/DefinitelyTyped的性能损失

所以，按照这种理解，我选择（更多或更少）复归https://github.com/DefinitelyTyped/DefinitelyTyped/pull/34499 ，通过https://github.com/DefinitelyTyped/DefinitelyTyped/pull/39323。

smockle picture smockle 于 2019-11-02

机器人的性能指标基于测试中的内容，不幸的是，样式化组件测试在大小和（复杂）使用方面都与真正的应用程序相差甚远。 它尽其所能，尽其所能，但它并不总能找到 _every_ perf 问题。

（侧边栏：“git”意义上的“责备”——请不要冒犯~）

weswigham picture weswigham 于 2019-11-02
👍1

这是有道理的，谢谢@weswigham！

在我们可以在测试中发现这种性能回归之前，我认为最好的做法是恢复 PR https://github.com/DefinitelyTyped/DefinitelyTyped/pull/39323 ，所以我打开了 PR https://github.com /DefinitelyTyped/DefinitelyTyped/pull/40095这样做。

下周，我将根据共享的报告（例如 https://github.com/DefinitelyTyped/DefinitelyTyped/pull/39323#issuecomment-549015652）添加一个测试。 一旦它起作用，我们就可以（事前）评估类似于https://github.com/DefinitelyTyped/DefinitelyTyped/pull/39323 的其他解决方案

smockle picture smockle 于 2019-11-02

@smockle您是否尝试过运行最新版本 (4.4.2)？ 似乎性能错误又回来了，降级到 4.1.19 有帮助。

UPD：与 sc 类型 v5.0.1 相同

kachkaev picture kachkaev 于 2020-02-02
👍11

@sregg
我也是！！！

我的 VSCode（*实际上是 TS-SERVER）比以前慢。 使用样式组件后。
"@types/styled-components": "^5.1.0", "styled-components": "^5.1.1" "typescript": "^3.9.5"

JeGwan picture JeGwan 于 2020-06-23
👍5

将 TS 从 3.9.X 降级到 3.8.3 后，我的性能再次恢复正常。 使用"@types/styled-components": "^5.1.0"和"styled-components": "^5.1.1" 。

joaopaulobdac picture joaopaulobdac 于 2020-07-03
👍2

感谢@joaopaulobdac ，我一直在从事一个项目，它在打字稿评估方面比另一个项目慢得多，我花了很长时间才意识到样式化组件是罪魁祸首。 你的修复已经为我完成了。 似乎没有使用 typescript 的任何 3.9x 功能，所以这是一个非常轻松的切换！

Andrew1431 picture Andrew1431 于 2020-07-13

那么我们应该创建一个新问题吗？ 不升级只是短期解决方案。

fabb picture fabb 于 2020-07-13

我在 2020 年 6 月的最新版本（版本 1.47）和“@types/styled-components”：“^5.1.1”中遇到了同样的问题

BjMrq picture BjMrq 于 2020-07-14

使用带有样式组件类型版本5.1.1打字稿3.9.3 5.1.1绝对会破坏我的 VSCode TS 服务器性能。 它绝对无法使用 :D 降级到 typescript 3.8.3似乎至少可以恢复一些性能，但这确实需要更多的关注。

lakaniemi picture lakaniemi 于 2020-07-16

@RyanCavanaugh重新开放？

fabb picture fabb 于 2020-07-16
👍15

可以确认，遇到同样的问题。

seklyza picture seklyza 于 2020-07-24
👍10

同样在这里，值得重新开放！

mmahalwy picture mmahalwy 于 2020-07-30
👍11

我确认我的 VSCode 已经开始卡住了。

gromov-io picture gromov-io 于 2020-08-20

我最终删除了样式组件，无论如何它并没有为我们提供大量的 react-native 好处。 带有扩展运算符和内联样式的普通旧 JS 对象在没有 TS 性能问题的情况下工作得很好，至少在 RN 上，IMO 最终比使用样式组件更容易阅读代码。

AndrewMorsillo picture AndrewMorsillo 于 2020-08-20
👍1

当我使用 VSCode 进行编码时，我正在 CSS-in-JS 天堂中体验地狱。

Aqzhyi picture Aqzhyi 于 2020-08-25

@AndrewMorsillo @hilezir我从 styled-components 切换到 styletron，使用 TS 4。styletron 的性能在 vscode 和浏览器中都要好得多。 但我不知道 React Native 上的 styletron。

joaopaulobdac picture joaopaulobdac 于 2020-08-25

@AndrewMorsillo @hilezir我从 styled-components 切换到 styletron，使用 TS 4。styletron 的性能在 vscode 和浏览器中都要好得多。 但我不知道 React Native 上的 styletron。

对我们来说进行这种更改为时已晚，但我还没有听说过 styletron 并且绝对比样式组件更喜欢它的外观。

Andrew1431 picture Andrew1431 于 2020-08-28

会不会有新的 issue 或者这个 issue 会重开吗？ @types/styled-components 5.1.2 和 TS 3.9.7 仍然存在很大的性能问题

JulianLang picture JulianLang 于 2020-08-30
👍13 👀3

花了一整天的时间试图弄清楚如何加速 VSCode 并且 _finally_ 发现它是@types/styled-components 。 安装后，只需在编辑器中输入任何内容都会导致tsserver.js （如通过 VSCode Process Explorer 所示）飙升 >100% CPU 并在内存中无限增长。 只需删除@types/styled-components解决此问题。

我使用的是 TypeScript 4.0.3 和@types/styled-components 5.1.3。

nfarina picture nfarina 于 2020-10-05
👍2

有人可以提出更好的样式组件替代方案吗？ 我的 vscode 完全冻结了。

prabhuignoto picture prabhuignoto 于 2020-10-07

有人可以提出更好的样式组件替代方案吗？ 我的 vscode 完全冻结了。

试试这个？

  1. https://material-ui.com/styles/basics/#material -ui-styles

  2. https://emotion.sh/docs/styled#styling -elements-and-components

Aqzhyi picture Aqzhyi 于 2020-10-07

实际上有一个 Pull Request 打开以提高styled-components的类型性能： https :

bdelaforest picture bdelaforest 于 2020-10-07
此页面是否有帮助？
0 / 5 - 0 等级

相关问题

jamespero picture jamespero  ·  3评论
jgoz picture jgoz  ·  3评论
alisabzevari picture alisabzevari  ·  3评论
Zzzen picture Zzzen  ·  3评论
svipas picture svipas  ·  3评论