为啥反应通常应该是产品依赖而不是开发依赖
Posted
技术标签:
【中文标题】为啥反应通常应该是产品依赖而不是开发依赖【英文标题】:why react should usually be a prod dependency and not dev-dependency为什么反应通常应该是产品依赖而不是开发依赖 【发布时间】:2018-07-29 10:25:35 【问题描述】:抱歉,如果我遗漏了一些明显的东西,但我似乎无法理解为什么 react(或 react-dom)应该是大多数项目的依赖项而不是开发依赖项.. 通常 src 是用 es6 编写的,并存储在 /src 或 /client 中,当有人想为 prod 构建项目时,他将创建 /build 或 /dist 在 finalize bundle.js 所在的位置(使用 webpack 等) .从那里(在 prod)它只是一个提供常规 js(包)和 html 文件的 Web 服务器。
我想念什么吗?
我不明白我为什么要对 prod 做出反应(当然,除非选择 s-s-r)..
非常感谢!
【问题讨论】:
你将把你的反应组件作为 createElement 函数,只有反应才能理解。 React 仍然在内部为您创建 DOM 并且需要运行 【参考方案1】:dependencies
需要run
,devDependencies
只需要develop
,例如:单元测试、Coffeescript 到 javascript 的转译、缩小、...
React
是一个依赖项,因为它包含在最终构建中。
如果是 React 应用程序,您的所有 JSX 都将转换为类似于 React.createElement
的语法,因此您将要求您的应用程序在运行时也具有 React。类似的方法如setState
和lifecyle functions
都在运行时执行。
事实上,react 是一个库,它公开了一些方法和 API 来访问和操作 DOM。
考虑这类似于jquery
或express
,您将其添加到生产构建中,因为它们在运行时被使用。
在创建 React 应用程序时,诸如 babel
、webpack
等仅用于创建包的内容将是开发依赖项,因为一旦生成打包的包,它就不需要在应用程序运行时生成
【讨论】:
【参考方案2】:我有同样的问题,发现 this article 解释得很好。
总而言之,将 react 依赖项放在哪里并不重要,因为 Webpack 会将它们捆绑到一个独立的文件中,并且代码在任何一种情况下都可以正常运行。但是,分离开发和生产依赖项可以更好地与其他开发人员就这些依赖项进行沟通。
【讨论】:
感谢您的回答。这就是我一直在寻找的。我已经看到将 ReactJs 放入 devDependencies 的代码,因为 webpack 已经在结果中打包了 React。很高兴知道它主要用于文档。【参考方案3】:dependency
是在您提到的 src/ 或 client/ 模块中导入的东西。您运行的代码取决于它,因此在生产包中是必需的。
如果它是 Babel
之类的东西,它可能是一个 devDependency,因为:
-
它没有在源代码中导入。
它是一个转译器,在编译时处理代码
但 React 并非如此。 setState
或生命周期挂钩等函数在运行时执行,这意味着库必须在运行时存在。
React 很可能被列为对等依赖项是一些流行的库。这是因为我们假设所有要使用这个库的项目都将安装React
。就像考虑react-bootstrap
的情况一样。它只能在 react 项目中运行,因此我们将 react 作为对等依赖项包括在内,以减少安装它的开销。
如果您需要一个会在编译时消失的框架,请查看Svelte。
【讨论】:
但是不是写:import react from 'react' 意味着webpack会将整个react库导入到bundle中吗? 是的,这意味着React
将被导入。 dependencies
是通过这种方式导入到代码中的。
如果我们忽略导入到webpack
的东西,我们将没有任何依赖关系。
Exactly..Webpack 为我完成了所有依赖项(在 dev 上),所以当我在我的 prod 服务器上点击 npm install 时,我为什么要“重新安装”反应。据我了解,当我在 prod 上安装 npm 时,我只需要表达我的服务器使用的任何依赖项(例如 API)
当你有一个包文件时,你只需要这个包。您不需要dependencies
或devDependencies
。你根本不应该这样做npm install
以上是关于为啥反应通常应该是产品依赖而不是开发依赖的主要内容,如果未能解决你的问题,请参考以下文章