ant-design/0ed2a35a-async.39440b34.js

(("undefined"!=typeof globalThis?globalThis:self).makoChunk_antd=("undefined"!=typeof globalThis?globalThis:self).makoChunk_antd||[]).push([["0ed2a35a"],{"0ed2a35a":function(e,a,t){"use strict";t.d(a,"__esModule",{value:!0}),t.d(a,"texts",{enumerable:!0,get:function(){return o;}}),t("21399db7");let o=[{value:"As a large component library, Ant Design has complex internal dependencies. Sometimes there is nothing change in antd, but the update of the internal dependencies may also cause the developer's build failure. For example, my recent mistake with ",paraId:0},{value:"path case error",paraId:0},{value:" made the build fail under Linux.",paraId:0},{value:"It's easier to find out the problem with the dependencies own by ourselves. But for third-party dependencies, it is often difficult to find out in the first time. Hours may have passed when developers report, making it somewhat difficult to find differences among hundreds of packages. We have accumulated some troubleshooting experience and will share it with you, but at the same time, in order to solve the problem faster, we have also done some extra things.",paraId:1},{value:"We have added a ",paraId:2,tocIndex:0},{value:"template site",paraId:2,tocIndex:0},{value:" for GitHub issue. Developers will see the following form when submitting issues, and developers will be asked to fill in the relevant information as completely as possible:",paraId:2,tocIndex:0},{value:"Most error problems can be combined to dig through antd version, React version, system, and browser version information which helps narrow the scope of troubleshooting as much as possible. Let's roughly determine if it's a general problem or a system-specific problem. Here we will not talk about component implementation bugs, but just talk about dependencies.",paraId:3,tocIndex:0},{value:"From the issue being discovered, we can reverse the time range through the commit CI of github:",paraId:4,tocIndex:1},{value:"Then through the issue description, you can determine the approximate package and which ones are related (for example ",paraId:5,tocIndex:1},{value:"#41236",paraId:5,tocIndex:1},{value:" from ",paraId:5,tocIndex:1},{value:"@rc-component/trigger",paraId:5,tocIndex:1},{value:", ",paraId:5,tocIndex:1},{value:"#15930",paraId:5,tocIndex:1},{value:" via ",paraId:5,tocIndex:1},{value:"@types/react",paraId:5,tocIndex:1},{value:"). Then check the version release status of the related package through npm:",paraId:5,tocIndex:1},{value:"When we find relevant updates, we will install the previous version for comparison to see if the build was successful. After checking one by one, we can determine which version the problem is, and we will also raise an issue for the corresponding GitHub (of course, if there is already one, just +1). At the same time, we also need to send a patch version to temporarily lock the corresponding version and remove it after the next update.",paraId:6,tocIndex:1},{value:"As you can see, the above troubleshooting method has a certain lag. We hope to reduce additional human labor by building regularly, and at the same time allow us to find problems faster. So we reused the ",paraId:7,tocIndex:2},{value:"create-next-app-antd",paraId:7,tocIndex:2},{value:" project as the base (in this way, if something goes wrong with the template project, we can also be detected in advance). Created a ",paraId:7,tocIndex:2},{value:"mock-project-build.yml",paraId:7,tocIndex:2},{value:" CI that executes every half hour, which periodically pulls ",paraId:7,tocIndex:2},{value:"create-next-app-antd",paraId:7,tocIndex:2},{value:" repo to build:",paraId:7,tocIndex:2},{value:"on:\n  workflow_dispatch:\n  schedule:\n    - cron: '*/30 * * * *'\n",paraId:8,tocIndex:2},{value:"Pass ",paraId:9,tocIndex:2},{value:"--depth=1",paraId:9,tocIndex:2},{value:" to only pull the last commit. Then execute ",paraId:9,tocIndex:2},{value:"yarn",paraId:9,tocIndex:2},{value:" to install dependencies to generate the corresponding ",paraId:9,tocIndex:2},{value:"yarn.lock",paraId:9,tocIndex:2},{value:" file, and finally execute ",paraId:9,tocIndex:2},{value:"yarn build",paraId:9,tocIndex:2},{value:" to build to completely simulate the construction process of a project.",paraId:9,tocIndex:2},{value:"Every time the build is successful, CI will cache the current ",paraId:10,tocIndex:2},{value:"yarn.lock",paraId:10,tocIndex:2},{value:" file. In this way, if the next build fails, we can easily pull the two files for comparison to troubleshoot the problem. Although ",paraId:10,tocIndex:2},{value:"actions/cache",paraId:10,tocIndex:2},{value:" does not allow cache keys with the same name, it allows ",paraId:10,tocIndex:2},{value:"restore-keys",paraId:10,tocIndex:2},{value:" to get the latest cache, which is very convenient:",paraId:10,tocIndex:2},{value:"- uses: actions/cache@v4\n  with:\n    path: ~tmpProj/yarn.lock\n    key: primes-${{ runner.os }}-${{ github.run_id }}\n    restore-keys: mock-proj-lock-file\n",paraId:11,tocIndex:2},{value:"Then monitor the build failure event and compare the ",paraId:12,tocIndex:2},{value:"yarn.lock",paraId:12,tocIndex:2},{value:" file to quickly find out the changed dependencies:",paraId:12,tocIndex:2},{value:"- name: \u{1F3A8} Diff Report\n  if: ${{ failure() }}\n  run: npx diff-yarn-lock --source=~tmpProj/yarn.lock --target=~tmpProj/yarn.lock.failed\n",paraId:13,tocIndex:2},{value:"We also push messages to the developer group through the IM push protocol when failed, so we can identify the problem in the first place. The complete script can be viewed ",paraId:14,tocIndex:2},{value:"here",paraId:14,tocIndex:2},{value:".",paraId:14,tocIndex:2},{value:"We have been continuously optimizing the problems encountered in the maintenance process. If you have any good ideas or suggestions in use, you are welcome to put them in our issue or discussion. Have a nice day.",paraId:15,tocIndex:3}];}}]);