我一看到这些玩意就不想写代码了怎么破

[sensui7]

写代码之前, 先搞出一堆依赖, 不是说和业务相关的, 就是开发时 , 所谓提高工作效率, 倒不是说不好, 问题是这些依赖今天好使, 下周 api 可能就变了, 3 个月后就 deprecated 了, 看到这 60 多个包, 什么灵感都没了.....我只想关掉编辑器.

我想问一下, 后端或者 app 或者桌面软件开发, 也这样吗, 我只了解一些 php, 我感觉那时候也没这些劳什子, 我用框架, CI, laravel, 我写的代码, 都跟我业务需求有关呐... ...

小生真诚请教后端, app, 桌面领域的人士现身说法...

"devDependencies": {
    "autoprefixer": "^6.7.2",
    "babel-core": "^6.22.1",
    "babel-eslint": "^7.1.1",
    "babel-loader": "^6.2.10",
    "babel-plugin-transform-runtime": "^6.22.0",
    "babel-preset-env": "^1.2.1",
    "babel-preset-stage-2": "^6.22.0",
    "babel-register": "^6.22.0",
    "chalk": "^1.1.3",
    "connect-history-api-fallback": "^1.3.0",
    "copy-webpack-plugin": "^4.0.1",
    "css-loader": "^0.26.1",
    "eslint": "^3.14.1",
    "eslint-friendly-formatter": "^2.0.7",
    "eslint-loader": "^1.6.1",
    "eslint-plugin-html": "^2.0.0",
    "eslint-config-standard": "^6.2.1",
    "eslint-plugin-promise": "^3.4.0",
    "eslint-plugin-standard": "^2.0.1",
    "eventsource-polyfill": "^0.9.6",
    "express": "^4.14.1",
    "extract-text-webpack-plugin": "^2.0.0",
    "file-loader": "^0.10.0",
    "friendly-errors-webpack-plugin": "^1.1.3",
    "html-webpack-plugin": "^2.28.0",
    "http-proxy-middleware": "^0.17.3",
    "webpack-bundle-analyzer": "^2.2.1",
    "cross-env": "^3.1.4",
    "karma": "^1.4.1",
    "karma-coverage": "^1.1.1",
    "karma-mocha": "^1.3.0",
    "karma-phantomjs-launcher": "^1.0.2",
    "karma-phantomjs-shim": "^1.4.0",
    "karma-sinon-chai": "^1.2.4",
    "karma-sourcemap-loader": "^0.3.7",
    "karma-spec-reporter": "0.0.26",
    "karma-webpack": "^2.0.2",
    "lolex": "^1.5.2",
    "mocha": "^3.2.0",
    "chai": "^3.5.0",
    "sinon": "^2.1.0",
    "sinon-chai": "^2.8.0",
    "inject-loader": "^2.0.1",
    "babel-plugin-istanbul": "^3.1.2",
    "phantomjs-prebuilt": "^2.1.14",
    "chromedriver": "^2.27.2",
    "cross-spawn": "^5.0.1",
    "nightwatch": "^0.9.12",
    "selenium-server": "^3.0.1",
    "semver": "^5.3.0",
    "shelljs": "^0.7.6",
    "opn": "^4.0.2",
    "optimize-css-assets-webpack-plugin": "^1.3.0",
    "ora": "^1.1.0",
    "rimraf": "^2.6.0",
    "url-loader": "^0.5.8",
    "vue-loader": "^11.1.4",
    "vue-style-loader": "^2.0.0",
    "vue-template-compiler": "^2.2.4",
    "webpack": "^2.2.1",
    "webpack-dev-middleware": "^1.10.0",
    "webpack-hot-middleware": "^2.16.1",
    "webpack-merge": "^2.6.1"
  },

[jakes]

版本号全改成指定版本，不用这种最低版本限定不就可以了？

[arzusyume]

有道德的开发者会遵循语义化版本规范 ( http://semver.org/lang/zh-CN/)
不放心的话就指定具体版本 ( https://docs.npmjs.com/misc/semver)

[AngelCriss]

负责任的告诉你，我做后端极少依赖其它库。

[lany]

基本都是自己的私人库。

[Tyanboot]

我做 py 和 PHP 的时候也是除了一些特殊的部分，比如图像识别， HTML 解析，之类的，很少像 js 一样动辄依赖几百个包的情况。。

[sagaxu]

以前 Java 的 spring 也这么麻烦，后来 spring-boot 应运而生

[sagaxu]

@Tyanboot

对的，连 isArray 这么一行代码就做到的事情，也单独的是个 package ，下载量还不低

https://www.npmjs.com/package/isarray

[watzds]

@sagaxu 好厉害啊，一天一百万下载量…！

[shyling]

不觉得依赖一些包有什么问题，另外上面写的包都不会乱在 patch 里加 breaking changes 的吧？
跟不上变化就别升级啊。。
另外很负责的告诉你，很多人的代码写的并不见得会比 npm 一个很简单的包里的好

[guokeke]

你可以不用这些，照样写。而且我看了这些依赖，没有什么像 isArray 那样的， webpack ， babel ， eslint ， express ， karma 这些打包，转译，测试，这些都是很良心的工具，一些插件也不是必须的，可以去掉。

[Miy4mori]

依赖上百个包的 java 后端挺常见的，现代软件开发可不就是靠第三方包嘛。

[FunctionOne]

我跟你有同感的。

[reeco]

一个 node_module 动辄几百 M

[kslr]

Laravel Composer 其实也很多我

[qhxin]

node_module 在 Win8 下面删除的时候尽然报错，路径长度超过了系统能接受的范围，打开新项目 phpstorm 就去索引，卡的要命，这设计真心醉醉的。不同意楼上拿 composer 来比较的，主要是 js 这套升级换代太快了，而且经常不兼顾旧代码，说句不好听的话就是没有责任心。

[isb]

用 yarn

[340244120]

一楼已经终结本帖了。。。

[kokutou]

@qhxin 长度超出是奇葩 windows 路径长度的限制。。。
不过好在因为 wsl ，现在 win10 已经可以一个注册表解除限制了。

[des]

@qhxin
@kokutou 删除可以用 robotcopy

[di94sh]

不需要，可能会用一两个库。

[lwbjing]

《前端的入门之切图 5 分钟，配置俩小时》，也是这样的。。

[libook]

不要用不稳定的包，像你说隔几天就出一次不兼容更新的，还不如不用。
大多高质量的包都会考虑相当长时间的向前向后兼容，甚至会有 LTS 版本。
为了确保不会被维护者坑，一定要固定包的版本号，不要用模糊版本号。
觉得不好用不想用就不要用，要看应用场景是否一定必要使用某个第三方包。

[vizards]

用 yarn 锁版本号

[coderfox]

一个是，限定版本号不要用最低版本，用等价版本。

例如：不要 ^1.0.0 ，要 ~1.0.0 。

另外一个是，可以用 yarn ，锁定版本。

[bdbai]

说 npm 超出 Windows 路径长度限制的，现在早就修复了好吗。
为了防止更新依赖引入 breaking changes ，请使用 yarn 。

[Quaintjade]

JS 原厂负重轮不够好用，各家都在造轮子，所以轮子多。你要做的是找出做得好的轮子，固定住型号批次。

[smithtel]

看到头像我居然点了一下。。。

[murmur]

dev app 只是构建工具而已

如果把 vs studio+.net runtime 做成 node_modules ，估计 dev 依存记事本都打不开提示超大

[qdwang]

然后每次一开始就要装半天 各种 build

[qdwang]

感觉 node 为二氧化碳的增加排放做了不少贡献

[murmur]

@qdwang npm3+hot module replacement 已经很好的改善这个问题了

[hengzhang]

楼主的头像太可怕了，已经上当

[plantain]

早上写了个相关问题的总结，楼主可以参考下： https://plantain-00.github.io/blogs/contents/js%E9%A1%B9%E7%9B%AE%E7%9A%84package%E7%89%88%E6%9C%AC%E7%AD%96%E7%95%A5.html

[lany]

@hengzhang 我刚刚也想说，什么时候有点赞功能了

[jason19659]

依赖肯定要的

[junnplus]

@shyling 如果是几个函数级别的 package 我觉得就没必要动不动就安装依赖包，还不如自己 copy 一份写一个 utils 解决呢

[shyling]

@junnplus 当然有区别，例如那个 isarray ，作者本来写的 Object.prototype.toString.call 后来做 perf 发现这样性能不是最好的，后来又去改了实现。
直接 copy 哪里会去维护这些不太可能成为瓶颈的小得性能提升呢？

[connection]

这是 vue 脚手架吧>_<

[azh7138m]

@kokutou 只是文件资源管理器的问题，换个三方的就好了

[Balthild]

所以你写代码之前为什么要看 package.json ？

[shyling]

@plantain 有点问题， react 是应该放在 deps 里的， dev 说的是开发使用， react 都打包到 bundle 里了

[plantain]

@shyling 分情况的，如果是 react 程序，实际运行的是 bundle ，在生产环境只需要那个 bundle ，不需要安装 react 包，那么运行 npm i --production 时就不应该安装 react ，所以不应该放到 deps 里；。

[shyling]

@plantain 其实我不知道你这么说你纯前端 spa 项目 npm i --production 能做什么事情。。。什么都不装了么

[shyling]

@plantain 哦，我又想了一想，其实不管是 deps 还是 devDeps 都是 npm 自己管理运行的，浏览器里的代码又不是通过 npm start / run 什么的执行的，所以说这里还是主要用于区分包的用途。

[plantain]

@shyling 很多项目的前端和 nodejs 是混在一起的，共用一个 package.json ，这种情况下 react 不放在 deps 下更合理；纯前端的话确实放在哪里都没太大影响。

[sensui7]

@Balthild 学到了, 原来不管 package , 直接撸. 稳.

@plantain
@shyling
你俩说的是其实是一个意思, 应用依赖于 react 运行, 所以放在 deps 里, 但是开发时 react 已经被打包到 bundle 里了. 所以生产环境不需要 react... 需要吗? 不需要吗?
一般的做法是 dev 里只放跟开发过程相关的包, 像 react 这类也放到 deps 里吧.

但前后端混在一起的话, 用 webpack 就比较麻烦

[Balthild]

@sensui7 要看 package 也是在某段代码中遇到某个语句时，去看它所调用的具体的那个 package ，怎么都轮不上看 package.json 里面的 package 列表吧？如果你想先了解代码中调用的包，文件头部难道没有 import xxx from "xxx"; ？

[sensui7]

@Balthild 其实就像把属性名前边放一个 _, 表示这是私有属性一样, 只是一种约定吧.包管理器, 除了自动管理依赖, 也是方便查看项目依赖的工具, 不是吗?
如果某个项目明明有 package.json, 结果是乱来的, 根本体现不出依赖, 完全还是手动复制粘贴的包, 那我觉得作者一定脑子有包.....

[Balthild]

@sensui7 package.json 表示的项目依赖，不一定是项目代码的依赖，也包括构建工具与构建工具的依赖。
要看项目代码的依赖，只有文件头部的引用语句是准确的。