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

This topic created in 3324 days ago, the information mentioned may be changed or developed.

写代码之前, 先搞出一堆依赖, 不是说和业务相关的, 就是开发时 , 所谓提高工作效率, 倒不是说不好, 问题是这些依赖今天好使, 下周 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" },

49 replies 2017-08-03 14:49:59 +08:00

jakes

Apr 15, 2017 via iPhone

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

arzusyume

Apr 16, 2017

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

AngelCriss

Apr 16, 2017 via Android

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

lany

Apr 16, 2017 via iPhone

基本都是自己的私人库。

Tyanboot

PRO

Apr 16, 2017 via Android

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

sagaxu

Apr 16, 2017

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

sagaxu

Apr 16, 2017

@Tyanboot

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

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

watzds

Apr 16, 2017 via Android

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

shyling

Apr 16, 2017

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

guokeke

Apr 16, 2017 via Android

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

Miy4mori

Apr 16, 2017 via iPhone

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

FunctionOne

Apr 16, 2017

我跟你有同感的。

reeco

Apr 16, 2017 via iPhone

一个 node_module 动辄几百 M

kslr

Apr 16, 2017 via Android

Laravel Composer 其实也很多我

qhxin

Apr 16, 2017 via Android

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

isb

Apr 16, 2017 via iPhone

用 yarn

340244120

Apr 16, 2017 via Android

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

kokutou

Apr 16, 2017 via Android

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

des

Apr 16, 2017 via Android

@qhxin
@kokutou 删除可以用 robotcopy

di94sh

Apr 16, 2017 via Android

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

lwbjing

Apr 16, 2017

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

libook

Apr 16, 2017

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

vizards

Apr 16, 2017 via iPhone

用 yarn 锁版本号

coderfox

Apr 16, 2017 via Android

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

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

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

bdbai

Apr 16, 2017 via Android

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

Quaintjade

Apr 16, 2017 via Android

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

smithtel

Apr 16, 2017

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

murmur

Apr 16, 2017

dev app 只是构建工具而已

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

qdwang

Apr 16, 2017 via iPhone

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

qdwang

Apr 16, 2017 via iPhone

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

murmur

Apr 16, 2017

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

hengzhang

Apr 16, 2017

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

plantain

Apr 16, 2017

早上写了个相关问题的总结，楼主可以参考下： 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

Apr 16, 2017

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

jason19659

Apr 16, 2017

依赖肯定要的

junnplus

Apr 16, 2017

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

shyling

Apr 16, 2017

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

connection

Apr 16, 2017

这是 vue 脚手架吧>_<

azh7138m

Apr 17, 2017 via Android

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

Balthild

Apr 19, 2017 via Android

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

shyling

Apr 19, 2017

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

plantain

Apr 19, 2017 via Android

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

shyling

Apr 19, 2017

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

shyling

Apr 19, 2017

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

plantain

Apr 19, 2017 via Android

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

sensui7

Apr 19, 2017

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

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

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

Balthild

Apr 21, 2017

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

sensui7

Apr 22, 2017

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

Balthild

Aug 3, 2017 via Android

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