@dodo2012 没必要捧一踩一，再说 cra 和 react 是两个东西。

@claneo 我还真没仔细看，我还以为 react-app-rewired 是 fork 的 react-script 呢。

@tyrealgray 我倒是有很多需要覆盖的，比方说上面说的 less modele，再比方说我现在的项目是 dev 时不使用 eslint-loader，prod 时使用 eslint-loader，比方说 eslint 配置中声明使用 webpack 配置中的 import/resolve，等等等等，都是 cra 做不到的

@claneo 我倒不是说 react-script 仅仅怎么样，而是说，如果我采用 react-app-rewired，就是将“维护 react-script”的工作，从我手里转移到 react-app-rewired 团队，而我们两者，都不如 cra 团队实力强。。。

@fanchangyong 刚刚试用了一下 2 楼说的 craco，说实话，乍一看还是挺符合我的预期的，但是我感到很奇怪的一点是，他暴露出来的接口跟 webpack 原本的接口竟然不一致。。。比方说在 webpack 中，alias 属性位于 exportObject.resolve.alias，可是 craco 暴露出来的接口中，该属性却位于 exportObject.webpack.alias，resolve 属性没了。。。所以用着用着，感觉不对劲了，react-scripts 封装一次，craco 再封装一次，给我一种很大的不安全感，估计确实得回到手撸 webpack 了。

倒不是手撸 webpack 多难（虽然确实不容易），而是我考虑的肯定没有 cra 团队那么全面，如果能直接使用 cra，就能受益于 cra 的每一次更新，这才是我的本意。

@fanchangyong 我跟你一样，参考他的实现手撸了一套适合自己的，可是就感觉很别扭，比方说他们那么大的团队，可能会不断地去支持 webpack 的新特性，如果能不 eject，在 cra 升级的时候，执行一句 yarn upgrade，再小修小补，就能获取 facebook 的团队积累，不是美滋滋？

@love https://danielwertheim.se/solution-to-issues-with-node-gyp-node-sass-on-windows/ https://github.com/nodejs/node-gyp/issues/1960
主要是, less 完全不会有这些问题, 而 sass 对比 less 并无不可逾越的优势。而且, 这并不是探讨 less 好还是 sass 好的问题, 而是 cra 如何优雅地使用 less module 的问题。

@fanchangyong
> cra 这东西感觉用作 demo 或者非常小的临时项目还行，严肃点的我建议还是用别的
有什么说法吗？我感觉 cra 还可以啊？

@Aynamic @Aynamic 谢谢, 可是我的问题并不是 less 还是 sass 的问题, 而是 cra 配置的问题。

@love 如果他确实是最佳配置，我肯定不瞎搞。可是，css 功能不足，sass 每次下载 node-sass 总是煎熬，挂梯子都下不下来，要一个 less 的 css module 不过分吧，可是 cra 如果不进行扩展就实现不了。

@ericgui 恰恰相反，我非常喜欢折腾 webpack，我只是认为自己的是野路子，想要站在 facebook 的肩上，扩展 cra，可是 cra 不让我好好的扩展。。。至于 parceljs，我确实没用过，可是感觉 webpack 挺好的，主要是用的人多，暂时不太想转...

@Hellert 谢谢，初步瞄了一下，好像刚好就是我想要的，再仔细看看

@jecshcier vue 也挺好，但是我不太喜欢模板语法，感觉不太`typescript`，更主要的是在等 vue 3.0 出来...


@yyfearth @rioshikelong121 不太像用 react-app-rewired + customize-cra, 因为这仅仅是将维护 react-scripts 交给了 react-app-rewired 的团队, 我不相信他们能做得比 facebook 好

@zqaq520 按照我 2 楼说的做就可以了

@GM 从 if (typeof arg === "string") 开始看就好了

退格键旁边的加减号简直是噩梦，加号稍微好一些，减号十次有九次是错的，要么是 0 要么是+...

canvas 有个方法叫 measureText，可以以此来精确地控制文字的换行，并算出 csv 每一项的高度，据此手动控制何时分页，效率可能会有些差，但才十几万条，应该不碍事。只是不知道对少数民族语的支持如何。

@theprimone 用 deep-equal 也不可能在组件每次渲染的时候比较啊，那样性能肯定炸了，还是要在每次发生对象操作的时候比较，跟 3l 的 forceUpdate 差不多吧应该

@iamppz reducer 确实挺好，只是不太喜欢这种风格，貌似是目前的最优方案了


@theprimone 对象层级比较深，对象中有数组，数组里面是对象，对象下边还有数组，深层对象的属性变动不好监听，可能又会回到下面这种样子:
setData({
...data,
key: [
...data[key],
val,
],
})
这仅仅一层就已经这么丑了，要是三四层，就丑的没边了，而自动调用，前提还是得监听数据的变化，可能得试试 proxy

@WittBulter 你的封装比我的帅，你看我的：

const [uselessFlag, setUselessFlag] = useState(false)
const updataComponent = useCallback(() => {
setUselessFlag(!uselessFlag)
}, [uselessFlag])

@WittBulter 谢谢，我现在就是这样处理的，可是一方面到处都是 forceUpdate，有点丑，另一方面全程需要手动管理，感觉回到了 jQ，很难受...

@iamppz 比方说

const village = new Village()

const familyA = village.datas[3]

const personS = familyA.datas[4]

personS.age += 1

这样的情况，我目前的处理是，在每个操作时，手动通知组件更新，可是这也太傻了...

(ps: 可以全量更新 village, 如 setVillage(newVillage), 但是对于复杂的, 数组和对象混杂的对象, 这样做很累, 还丑)