此af-webpack配置文件在dev模式中可以顺利加载 aut 和 local scss 样式,但是生产模式中,样式是不被打包进去的,看了一下配置,我的import 和 sass 配置并没有外层并没有指定模式,为什么生产模式和开发不一样了呢?
{
"entry": "src/index.js",
"sass": {},
"disableCSSModules": true,
"publicPath": "/",
"outputPath": "dist",
"proxy": {
"/auth/*": {
"pathRewrite": {
"^/auth": ""
},
"changeOrigin": true
},
"/crm/api/*": {
"changeOrigin": true,
"pathRewrite": { "^/crm/api": "" }
}
},
"theme": {
"@primary-color": "#1DA57A",
"@link-color": "#1DA57A",
"@border-radius-base": "2px",
"@font-size-base": "16px",
"@line-height-base": "1.2"
},
"extraBabelPlugins": [
"transform-runtime",
["import", { "libraryName": "antd", "style": true }]
]
}
没理解问题,给出可重现代码吧。
@sorrycc Sorry, 我还是尝试一下自己配置webpack把,我不能忍受想扩展一下配置就来这里看issue的事实,这真的太浪费时间了。我可以理解阿里内部dva的实践,为了内部统一,基于react的环境&组件库搞出来的一套开发体系,对于umi作为一个react的环境支撑,有固定的版本可能帮助你们公司减少开发中遇到的一些环境问题。。。但它并不适合开源,这是给别人用的,很多人在开始用(roadhog | umi)与遇到问题回退不了(只熟悉webpackConfig)这种情况下进退两难,我看一了一下这几个项目的Issue,大部分都是环境配置,而且,您觉得 umi 这个它作为解决什么问题才开源出来的呢?只是它因为dva依赖了它嘛?有多少人单独使用了它,我觉得如果只是一个附属品没有单独使用的价值,,为什么要单独拆分出来呢... 是不是违背了dva的初衷才单独拆分呢? 那么dva为什么要依赖于它呢? 所以,我想能够把它与umi选择性的使用最好,要考虑到使用体验...而且每天解决这么多issue不累吗? .
抱歉,没有能解决你的问题。
不过看描述,你似乎没有理解 umi/roadhog/dva 的区别,
你应该是使用 roadhog 遇到的问题,作为一个 webpack 的上层封装工具,他带有一定的主观意愿,比如推荐内置使用 css-modules、css 在 dev 时打包在 JS 里而 build 后提取为 css 文件等等这些我们认为的最佳实践,而 roadhog 的价值正是在于把我们认为的最佳实践沉淀为工具,但看起来不是每个人都喜欢。
umi 不是你正在用的,就不展开说了。
所以,如果你对 webpack 及周边生态很熟悉,其实完全可以直接使用 webpack,事实上我们内部也有这部分用户,因为有些应用的需求和 roadhog 内置的相距甚远,我会推荐他们直接用 webpack。
roadhog 和 umi 里的 af-webpack 不是一个东西嘛
@sorrycc
刚进来页面正常,刷新后感觉css文件没有加载进来,页面乱乱
Most helpful comment
抱歉,没有能解决你的问题。
不过看描述,你似乎没有理解 umi/roadhog/dva 的区别,
你应该是使用 roadhog 遇到的问题,作为一个 webpack 的上层封装工具,他带有一定的主观意愿,比如推荐内置使用 css-modules、css 在 dev 时打包在 JS 里而 build 后提取为 css 文件等等这些我们认为的最佳实践,而 roadhog 的价值正是在于把我们认为的最佳实践沉淀为工具,但看起来不是每个人都喜欢。
umi 不是你正在用的,就不展开说了。
所以,如果你对 webpack 及周边生态很熟悉,其实完全可以直接使用 webpack,事实上我们内部也有这部分用户,因为有些应用的需求和 roadhog 内置的相距甚远,我会推荐他们直接用 webpack。