我刚才测试了一下，https 的页面是可以正常连 ws://开头的 websocket 的服务的（可以通过这个地址测试： https://plantain-00.github.io/ws-tool/）

不过常规的实践是，websocket 连接时发出的请求是 http 协议（可以是 http 或 https，分别对应 ws:// 和 wss://，后者会对通信加密，连接的请求可以携带 cookie、token 等用于身份验证，身份验证失败可以直接断开连接，保证之后的数据帧的安全），之后的双工通信消息则是通过 tcp 来发送的（不涉及 http，也就没有 https 的概念）。

所以没必要那么做，websocket 服务直接使用 wss:// 就好，只会加密 websocket 的连接部分，后面的数据帧是不会加密的。

1、 @types 下的库确实经常 break，所以用的时候要固定版本号
2、 @types 下的库就是社区维护的，流行库用的人多，贡献的人多，也就越完善，小众库用的人少，如果你要用，你也可以完善的啊，例如我就创造了 18 个 @types3、DefinitelyTyped 的 issue 很少有人看，有这时间，PR 都写好了
4、如果提的 PR 还没合并发布，代码里可以先用 any 写，等发布了再更新
5、如果只是简单用到几个方法，可以在 d.ts 文件里做声明，类似于：

declare module "foo" {
export bar():void;
}

标准方法难道不是 https ？

给个提示好避坑啊，或者在类似看准这样的网站发个评价吧。

用来大幅提高接口的灵活性。
缺点是因为默认每个字段一个查询，会默认导致后端性能大幅降低。实际使用时，一般还需要合并查询的一层架构，后端架构需要改。

很多面试管官，是临时拉来面试的，让你做自我介绍时，才开始看简历。

自己搞台服务器作代理？

向 IT 申请白名单？

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

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

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

如果一个功能开发完了，在合并之前，会有一堆人站你电脑前看效果，指点半天，有了这个 robot ，可以让他们自己打开那个测试 URL 去看，也就不会打扰自己接下来的工作了。

@qfdk 服务部署完成之后，就像 demo 里的那样，如果有人提交了一个 merge request ， robot 会根据新代码自动创建一个测试应用，并对外贴出地址， review 的人就可以查看程序被改成什么样， pm 也可以在合并前查看改后的效果了。

@LeoQ 不一样的， travis 一般用来做单元测试，这个可以临时创建测试程序， code review 的时候其他人就可以访问这个测试程序，查看页面效果等等，可以认为每个 pull request 都会生成一个测试环境，如果 pull request 不 merge 也不 close ，产生的测试环境会一直存在的。
而 travis 跑完测试，环境就释放掉了。

@LeoSocks 上海的
@snail1126
@fzleee 感觉快是个亚文化了，我还看到了周围有苹果的公益广告牌，锻炼什么的。
跑道在公园外面，不收费，空气也不错，如果我住在附近，肯定天天跑。

先确定扩展点在哪些地方，再据此抽象出插件的数据结构，界面上有功能来管理插件，安装后可以保存已经安装的插件，主系统依据保存的插件列表，动态加载插件，根据后端的语言和前端的模块模式，加载方式会有区别。
宽泛的说，大致就是这样的。