哦 没看清楚 是你入了 SetApp 把原来用的软件许可转让这样吧

SetApp 不是绑定账号的吗 不存在每个软件单独的许可证吧

我记得是每个账号可以安装在两台机子上 然后这两台机子可以随便装里面的软件

就像云端软件一样 你顶多和别人共享账号密码 没办法单独转让吧

一年前用的 SetApp 是这样的 选择不知道是不是还这样

不可能的 Apple 压根就没打算让 iOS App 运行在 macOS 上面 也压根没打算做的像 UWP 那样
Apple 做的只是做了它早就应该做的事情 就是把 iOS 的 UI SDK 移植到 macOS
这个只能说是方便开发者 希望开发者不要再忽略 macOS 的原生应用（然并卵）

你说的权限那些的 今年 macOS 确实有加强 但是和你说的这个 没啥关系

而且这次 UIKit 还是内部使用 没有开放给开发者

本来之前就说了今年的 iOS macOS 主要来修 bug 的 主要更新都推迟到 2019 了
有这么几个功能更新已经算不错了 明显就是实在没啥好说的 只好把鸡毛蒜皮的更新都拿出来了

罗技有静音鼠标和键盘可以考虑一下

同意楼上 只要记住顺时针 “上右下左” 就够了
如果少了最后一个左 那么就用右的值
如果还少了一个下 那么就用上的值
如果只有一个值 当然就全部都用了

解决办法很简单啊 为什么要跳过验证 直接安装证书就好了
不想验证用 ws 就好了啊 为啥还要用 wss

另外 我之所以最后选择第一种方法的主要原因 是因为方便开发和 debug
因为在开发项目的时候 经常要对 npm 包里面的组件进行修改 和 debug
导出 bundle 虽然可以用 source map 来 debug 但是没办法直接修改代码 立即 debug
必须 修改组件代码 -> 打包发布 -> 主项目 npm i 新版本 -> debug -> 修改组件代码 -> ...
非常耗时和浪费精力

改用直接使用 jsx 源代码 然后 npm link 或者 yarn workspace
一切就和没有 npm 包组件化一样方便了

这里 webpack 坑比较多 我现在都是不用打包的组件 直接引用源代码 基本上就是你第一种方法

导出 bundle 其实也可以 但是你 external react 是不够的 要 external 所有的 依赖 除非你 100% 确定这个依赖是你这个组件独有的
external 所有依赖后 bundle 文件就比较小了 而且不用担心 因为整个项目的 webpack 会把依赖打包进去
否则同一个依赖 如果其他地方有用到 会被打包多次 造成文件非常大

另外如果项目的多个组件用了不同版本的依赖 多个版本会被打包起来 导致最终 bundle 非常大
最容易碰到的例子就是 lodash 和 moment 两个库 本身就挺大的 加上不同组件及其依赖使用了不同版本或者不同发布方式的版本
比如 lodash 有 cjs 版本 es 版本 模块化的 cjs 版本 模块独立的发布的 cjs 版本 而且每种还可能有不同的 version 我之前就遇到过一个项目里面 lodash 就 4-5 个不同的拷贝被打包 每个 10k - 90k 不等
然后是 moment 的 locale 需要在打包的时候排除 否则非常大
这个可以通过修改 webpack 的配置来统一版本

我接触过的一个项目 一开始每个组件自己 bundle 然后项目再 bundle 结果各种重复打包 一个简单的 webapp 可以到 10M 的 JS bundle
通过各种办法 在没有减少任何功能 组件 和 依赖的情况下 减少到 250K JS + 100K CSS + 80K 字体文件

@xuuuu @littleylv APFS 下 CP 没有 复制粘贴快
复制粘贴不管文件大小 只要是同一个分区 都是 毫秒完成 而且占用空间也不增加
而且还不是 symlink 或者 hardlink 虽然实际上相当于 hardlink

另外其实还有一个好处就是 因为 node_modules 独立
所以可以直接修改依赖而不影响其他项目
尤其是在 debug 的时候 发现依赖的包里面有问题
甚至可以在 npm postinstall 里面直接 patch 依赖的包

@yuann72 你说的当然可以 但是问题就出在 “检查下所有项目的 package.json ”
也就是说 要么在 cleanup 的时候整个系统寻找 package.json
要么在 install 的时候需要记录每一个 package.json 存在的路径
都不是一件容易而且有效率的办法

否则 你在做清理的时候 你没办法知道有没有其他项目在使用你想要清理的包
这样一来 就意味着 所有 node 的项目就不是 portable 的 而且也不能随便移动位置和直接删除

现在 node_modules 最大的好处就是 node 项目大部分情况是 portable 的
只要 OS 兼容 Node 版本 兼容 你可以随时挪动位置 或者 删除 而且不影响其他项目
另外 如果你一个项目的包弄糟了 只需要删掉 node_modules 重来就好

我觉得唯一的问题 不是 node_modules 太大 而是文件太多 目录太复杂
我觉得可以学其他的语言把文件打包一下 比如 jar war phar 这些 zip 一下
而且由于有可能会有不少重复文件 去重再压缩估计会小不少
然后在运行时按需求解压 因为很多时候 并不是所有文件都有用到
而且现在的机器性能 解压缩 zip 的时间基本上可以忽略 搞不好从 IO 角度
从 zip 读取可能比加载一大堆文件还要快

这个现在可能不是很必要 但是以后有 webasm 了 打包一下其实可以考虑的

@wlwood @janxin @maichael 其实可以的 多个项目其实可以共享全部或者部分 node_modules
node 会自动向上层目录寻找 所以如果有公共的依赖 而且版本一致 可以提取到上层目录的 node_modules 实现共享
或者 如果你这些项目的依赖完全一致 可以把其中一个 node_modules 放到上层目录 然后把其他的删掉 或者 symlink
如果你觉得太麻烦 有工具会自动帮你弄：yarn workspace
它会自动解决多个项目的相互依赖 同时提取公共的部分到同一个 node_modules
其他的项目会 symlink 到这个 node_modules 里面的依赖

@chenstack 不一定要 symlink 其实 node 会自动往上层目录找 另外 yarn workspace 最适合这种情况 会自动 symlink

@beginor 放全局目录也不一定是好事 如果你项目多 全局目录会非常大
而且 如果你要删除一些项目的时候 全局目录就没办法清理 只会越来越大 而且你还不敢随便删除

@wlwood 其实你说的不完全正确 npm 有 cache 的 如果有相同的依赖不会重复下载 但是由于每个项目是独立的 node_modules 自然会有独立的拷贝
但是我觉得从部署的角度而言 独立 node_modules 其实比较方便和干净
你只要把项目连同 node_modules 一起打包和拷贝 只要 OS 和 Node 相同 就可以直接跑起来
而且删除的时候 也很干净 不会在 global 留下不再需要的包

另外同一个项目下面 如果版本不同 NPM 倾向保留多个版本 这个是 node 社区的问题
不同版本（一般除了_._.x 修正版本）之间往往不兼容 而且也有可能会有包锁定依赖版本
NPM 现在的方法 其实是比较省事的 如果要 merge 和 flatten 反而会造成很多问题
目前新版本的 NPM 和 Yarn 就会做一些 merge 和 flatten 结果每次更新依赖的时候 会造成一些问题

自然 现在开发机器没有 16G 啥都跑不起来
一两个 IDE + 一堆浏览器 8G 就要爆了
更不用说开虚拟机或者 Docker

当然 如果是远程桌面 就无所谓了
但是开发用的服务器内存就更多了
至少得都是 128G 起吧 CPU 估计也得 4x16 core

会不会因为你 iPhone 不信任这台 Mac
如果不信任的话 是充不了电的

楼上开玩笑呢 Promise.all([...]) 返回的当然是一个 promise 当然有 then 方法
是 then 里面的 values 是一个数组 是每个 promise 的结果
async/await 完全是 promise 的语法糖 完全等价的
用 async/await 还是 promise 纯粹是怎么写的选择 效果是一样的

LZ 的问题是 谁叫你把 reject 给注释掉了 你如果换成 resolve 我也就不追究了
你直接 return 是什么意思？也就是说一旦 err 了 这个 Promise 就永远 pending 它的 then 永远不会执行
所以你再用 Promise.all 只要里面又一个 err 那么你的 then 永远不会执行

@asaxing VSCode 将来会有这个能力
就是 File System Provider API
但是还在实验阶段

在这个 API 实现 并且有扩展使用之后 才有可能做到你希望的那样
否则一定是先下载到本地 然后上次回去那种

@mchl @songz 没区别的 因为 Number(0.0000008) === 0.0000008
parseInt(string) 所以都会被转换成 string
而 String(0.0000008) === '8e-7'
parseInt 不支持科学计数
所以 parseInt(0.0000008) === parseInt('8e-7') === 8

而 parseFloat 支持科学计数 所以没问题
parseFloat(0.0000008) === parseFloat('8e-7') === 8e-7 === 0.0000008

@vjnjc 因为 RN 不是 WebView 理论上没办法直接放在服务器上面运行 必须下载到本地
用 Cordova/PhoneGAP 或者 Ionic (基于 Cordova) 或者直接用 WebView 就可以直接用服务器上面
但是如果你直接把 App 放服务器上面 那这个 App 本身意义就不大 如果是苹果 会直接拒收
而且体验估计也不好 因为没办法离线使用
所以就算用 WebView 主程序一般也是放在 apk/ipa 里面的 里面某些在线功能可能会跳转到服务器页面

你提到的 基本上是说 “热更新” 的概念 Android 下面是没啥问题的 就算你用 Java 写 现在也能做到热更新
但是在 iOS 下 虽然以前都有不少热更新的 App 由于苹果不允许热更新 所以现在大家也不用了 就算用 RN 也要注意了