【问题标题】:Worth removing unused imports in big codebase?值得在大型代码库中删除未使用的导入吗?
【发布时间】:2023-03-11 03:40:01
【问题描述】:

在运行一个检查未使用的imports 的脚本(例如import XYZ from 'dir/XYZ.jsx',其中XYZ 从未使用过)后,我遇到了大约300 个存在此类问题的文件。这些文件中的大多数都缺少类似的内容,例如 Proptypes for React (import PropTypes from 'prop-types')。

听说webpack/babel 导入后缓存文件。如果这是真的,是否值得删除这些多次出现的未使用的导入,或者我应该不理会它们?

请注意,我正在为 performance reasons 和代码清洁度做这个项目。

【问题讨论】:

  • 我要做的第一件事是查看编译后的文件,看看 Babel 是否将导入转换为 require 或者它是否只是忽略导入

标签: javascript node.js webpack babeljs


【解决方案1】:

您已经回答了自己的问题:

请注意,我做这个项目是出于性能原因,也是为了 代码清洁度。

但是,让我们用一个示例场景和一些用例来打破答案。

场景

假设我们有一个预测应用程序。当用户转到每日预报路线时,他只想获取有关当天的信息。

用例

  1. 作为应用程序的用户,如果在日常路线上,由于某种原因我们加载了一个或多个库,从未使用过,是否会造成性能成本?记住这些库:
    1. 有某种类型的执行时间。想象一下,在导入的模块中,我们实例化一个新对象或执行一些繁重的处理。
    2. 为用户增加了网络开销。
  2. 作为开发人员的观点,如果我看到一个包含大量导入库的文件,第一眼看是否足够清晰?
    1. 如果我在DailyComponent 中导入weeklyForecast 实用程序会怎样?我的意思是它具有误导性和混淆性,除非您查看整个DailyComponent。也许有人会说我们为此提供了 Linter。但是,如果您不遵守 Linter 的规则和约定,为什么还要使用它呢?

从技术上讲,如果您导入一些从未使用但服务于用户的东西,则会导致性能损失(用例 1)。我建议您检查webpack optimization practices(最小化、重复数据删除、块)。

你也知道Webpack Code Splitting吗?

代码拆分是 webpack 最引人注目的特性之一。这 功能允许您将代码拆分为不同的包,这些包可以 然后按需或并行加载。它可以用来实现 较小的捆绑包并控制资源负载优先级,如果 正确使用,会对加载时间产生重大影响。

现在想象一下,如果您在应用中进行代码拆分,但仍有许多未使用的导入。 Тhat 会增加初始应用加载时间,违反代码拆分思想。

结论

对于新项目,显然包含未使用的导入没有任何好处。

根据您的情况,您可以测量有和没有未使用的导入的特定路线的加载时间。大多数 IDE 都提供此功能来删除未使用的导入,因此您可以计算影响。

【讨论】:

  • 感谢您提供的信息丰富的回答。我必须小心的一件事是删除看似未使用的导入,例如React,因为即使它看起来没有被使用,因为一旦代码被转译,文件中你再也看不到React这个词它把这样的事情:<div /> 变成了这个:React.createElement('div')See here
  • 我在答案中添加了一个结论部分。例如 PHPStorm(IntelliJ 平台)有选项 Code -> Optimize imports。它尊重您提到的React 案例。我刚刚测试过了。
猜你喜欢
  • 2015-09-06
  • 1970-01-01
  • 1970-01-01
  • 2016-05-10
  • 2015-08-14
  • 2016-07-26
  • 2014-04-11
  • 2022-10-31
  • 1970-01-01
相关资源
最近更新 更多