如何管理多个环境的 ASP.NET Core bundleconfig.json?
How to manage ASP.NET Core bundleconfig.json for multiple environments?
在开发环境和生产环境中使用 ASP.NET 核心 bundleconfig.json
的最佳做法是什么?之前的捆绑器 (BundleCollection) 会注意 DEBUG 编译器指令,而不是在调试时缩小脚本列表。
新范例似乎是在 HTML 模板中包含 <environment>
标记,用于测试 ASPNETCORE_ENVIRONMENT
值。尽管我没有看到将该环境变量合并到 bundleconfig.json
工作流程中的方法。
我看到的一种方法是为 bundleconfig.json
中的每个包输出维护 2 个列表,缩小版和非缩小版,以便可以调试 JavaScript。或者,我可以在开发 <environment>
标签中放置指向未捆绑 JavaScript 的直接链接,然后在 production/staging <environment>
标签中引用捆绑和缩小版本。
无论哪种方式,都需要维护 2 个 JavaScript 文件列表(所有这些都适用于 CSS 文件)。这对我来说似乎是倒退了一步,之前你只需要维护一个源文件列表,而 BundleCollection 只会在适当的时候缩小。
我是不是遗漏了什么,或者我是否需要更进一步调查 Gulp 以便能够处理不同的环境?
我想我找到了答案。我正要创建一个 HTML 帮助程序来读取开发环境的 bundleconfig.json
,但看来我不是第一个认为这是个好主意的人。请注意,.NET Core 实现链接到页面底部
https://github.com/madskristensen/BundlerMinifier/wiki/Unbundling-scripts-for-debugging
编辑
对于 .NET Core 实现,对 bundleconfig.json
的引用期望它位于 /Configs 文件夹中,这在您的项目中可能是也可能不是。对我来说,我只是把它放在项目的根目录中。
编辑
因此,如果源文件位于 wwwroot 文件夹之外,这将不起作用。将文件放在 wwwroot 文件夹之外是完全合理的,所以我正在研究让 html 帮助程序指向一个路径,该路径将在调试模式下流式传输文件
可能的解决方案
这是我对解决方案的演变:
https://gist.github.com/rupe120/512a9eb837383963f80fd9ef4984eb15
更新
我修改了我的解决方案以在路由定义中使用 {*filePath}
,因此现在无需对路径进行编码
更新
我认为这是我要做的最后一次重大更新。我用 bundleconfig.json
中的 outputFileName
值替换了静态基本路由字符串。所以现在调试路由的数量与缩小文件的数量一样多,而且不用担心名称冲突。此外,您可以在调试时看到哪些文件包含在哪个包中,我认为这很酷。
我和 Josh 一起处理这件事,不得不维护两个列表简直是疯了。有没有人在不使用 MvcHtmlString 帮助程序的情况下返回更好的内置解决方案!
"sourceMap": 真
如果在 bundleconfig.json 中启用,这将启用对您的 js 的调试
但我注意到,如果您要捆绑它,它不会正确生成地图,引用组合文件和每个映射文件...
Smidge 似乎提供了这个功能 - 带有一个简单的标志 - debug="true"
<environment names="Development">
<script src="my-awesome-js-bundle" type="text/javascript" debug="true"></script>
</environment>
<environment names="Staging,Production">
<script src="my-awesome-js-bundle" type="text/javascript"></script>
</environment>
Webpack 或 gulp 是要走的路 - 哪一个,这是值得商榷的。
我不认为这是最佳实践,但以下内容对我有用。
在 bundleconfig.json
中,我准备了一个包用于开发,一个用于生产。
用于开发的 Bundle 只是串联的文本,易于阅读和调试。
用于生产的捆绑包已缩小,并且可以选择包含源地图。
{
"outputFileName": "wwwroot/script.bundle.js",
"inputFiles": [
"wwwroot/node_modules/popper.js/dist/umd/popper.js",
"wwwroot/node_modules/jquery/dist/jquery.js",
"wwwroot/node_modules/bootstrap/dist/js/bootstrap.js"
],
"minify": {
"enabled": false,
"renameLocals": false
}
},
{
"outputFileName": "wwwroot/script.min.js",
"inputFiles": [
"wwwroot/script.bundle.js"
],
"minify": {
"enabled": true,
"renameLocals": true
},
// Optionally generate .map file
"sourceMap": false
}
重点是,生产包仅使用开发包。这样我就只需要保留一个列表。
在需要JS的页面上,我添加了两个bundle的标签。
<environment include="Development">
<script src="script.bundle.js" type="text/javascript"></script>
</environment>
<environment exclude="Development">
<script src="script.min.js" type="text/javascript"></script>
</environment>
在开发环境和生产环境中使用 ASP.NET 核心 bundleconfig.json
的最佳做法是什么?之前的捆绑器 (BundleCollection) 会注意 DEBUG 编译器指令,而不是在调试时缩小脚本列表。
新范例似乎是在 HTML 模板中包含 <environment>
标记,用于测试 ASPNETCORE_ENVIRONMENT
值。尽管我没有看到将该环境变量合并到 bundleconfig.json
工作流程中的方法。
我看到的一种方法是为 bundleconfig.json
中的每个包输出维护 2 个列表,缩小版和非缩小版,以便可以调试 JavaScript。或者,我可以在开发 <environment>
标签中放置指向未捆绑 JavaScript 的直接链接,然后在 production/staging <environment>
标签中引用捆绑和缩小版本。
无论哪种方式,都需要维护 2 个 JavaScript 文件列表(所有这些都适用于 CSS 文件)。这对我来说似乎是倒退了一步,之前你只需要维护一个源文件列表,而 BundleCollection 只会在适当的时候缩小。
我是不是遗漏了什么,或者我是否需要更进一步调查 Gulp 以便能够处理不同的环境?
我想我找到了答案。我正要创建一个 HTML 帮助程序来读取开发环境的 bundleconfig.json
,但看来我不是第一个认为这是个好主意的人。请注意,.NET Core 实现链接到页面底部
https://github.com/madskristensen/BundlerMinifier/wiki/Unbundling-scripts-for-debugging
编辑
对于 .NET Core 实现,对 bundleconfig.json
的引用期望它位于 /Configs 文件夹中,这在您的项目中可能是也可能不是。对我来说,我只是把它放在项目的根目录中。
编辑
因此,如果源文件位于 wwwroot 文件夹之外,这将不起作用。将文件放在 wwwroot 文件夹之外是完全合理的,所以我正在研究让 html 帮助程序指向一个路径,该路径将在调试模式下流式传输文件
可能的解决方案
这是我对解决方案的演变:
https://gist.github.com/rupe120/512a9eb837383963f80fd9ef4984eb15
更新
我修改了我的解决方案以在路由定义中使用 {*filePath}
,因此现在无需对路径进行编码
更新
我认为这是我要做的最后一次重大更新。我用 bundleconfig.json
中的 outputFileName
值替换了静态基本路由字符串。所以现在调试路由的数量与缩小文件的数量一样多,而且不用担心名称冲突。此外,您可以在调试时看到哪些文件包含在哪个包中,我认为这很酷。
我和 Josh 一起处理这件事,不得不维护两个列表简直是疯了。有没有人在不使用 MvcHtmlString 帮助程序的情况下返回更好的内置解决方案!
"sourceMap": 真
如果在 bundleconfig.json 中启用,这将启用对您的 js 的调试 但我注意到,如果您要捆绑它,它不会正确生成地图,引用组合文件和每个映射文件...
Smidge 似乎提供了这个功能 - 带有一个简单的标志 - debug="true"
<environment names="Development">
<script src="my-awesome-js-bundle" type="text/javascript" debug="true"></script>
</environment>
<environment names="Staging,Production">
<script src="my-awesome-js-bundle" type="text/javascript"></script>
</environment>
Webpack 或 gulp 是要走的路 - 哪一个,这是值得商榷的。
我不认为这是最佳实践,但以下内容对我有用。
在 bundleconfig.json
中,我准备了一个包用于开发,一个用于生产。
用于开发的 Bundle 只是串联的文本,易于阅读和调试。
用于生产的捆绑包已缩小,并且可以选择包含源地图。
{
"outputFileName": "wwwroot/script.bundle.js",
"inputFiles": [
"wwwroot/node_modules/popper.js/dist/umd/popper.js",
"wwwroot/node_modules/jquery/dist/jquery.js",
"wwwroot/node_modules/bootstrap/dist/js/bootstrap.js"
],
"minify": {
"enabled": false,
"renameLocals": false
}
},
{
"outputFileName": "wwwroot/script.min.js",
"inputFiles": [
"wwwroot/script.bundle.js"
],
"minify": {
"enabled": true,
"renameLocals": true
},
// Optionally generate .map file
"sourceMap": false
}
重点是,生产包仅使用开发包。这样我就只需要保留一个列表。
在需要JS的页面上,我添加了两个bundle的标签。
<environment include="Development">
<script src="script.bundle.js" type="text/javascript"></script>
</environment>
<environment exclude="Development">
<script src="script.min.js" type="text/javascript"></script>
</environment>