logoNamu Design

⌘ K
  • Design
  • Development
  • Components
  • Blog
  • Resources
1.0.0
  • Happy Work Theme
  • Where is the dynamic style?
  • Suspense breaks styles
  • Bundle Size Optimization
  • Hi, GitHub Actions
  • To be what you see
  • Pain of static methods
  • SSR Static style export
  • Dependency troubleshooting
  • Contributor development maintenance guide
  • Repost: How to submit a riddle
  • Tooltip align update
  • Unnecessary Rerender
  • How to Grow as a Collaborator
  • Funny Modal hook BUG
  • about antd test library migration
  • Tree's check conduction
  • Some change on getContainer
  • Component-level CSS-in-JS

Dependency troubleshooting

2023-04-13
@zombieJ
  • SSR Static style exportContributor development maintenance guide

    Resources

    Namu Design Charts
    Namu Design Pro
    Namu Design Pro Components
    Namu Design Mobile
    Namu Design Mini
    Namu Design Landing-Landing Templates
    Scaffolds-Scaffold Market
    Umi-React Application Framework
    dumi-Component doc generator
    qiankun-Micro-Frontends Framework
    ahooks-React Hooks Library
    Ant Motion-Motion Solution
    China Mirror 🇨🇳

    Community

    Awesome Namu Design
    Medium
    Twitter
    yuqueNamu Design in YuQue
    Namu Design in Zhihu
    Experience Cloud Blog
    seeconfSEE Conf-Experience Tech Conference

    Help

    GitHub
    Change Log
    FAQ
    Bug Report
    Issues
    Discussions
    StackOverflow
    SegmentFault

    Ant XTechMore Products

    yuqueYuQue-Document Collaboration Platform
    AntVAntV-Data Visualization
    EggEgg-Enterprise Node.js Framework
    kitchenKitchen-Sketch Toolkit
    xtechAnt Financial Experience Tech
    Theme Editor
    Made with ❤ by
    Ant Group and Namu Design Community

    As a large component library, Namu 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 path case error made the build fail under Linux.

    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.

    Confirm information

    We have added a template site 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:

    Issue Helper

    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.

    Determine the scope

    From the issue being discovered, we can reverse the time range through the commit CI of github:

    Commit List

    Then through the issue description, you can determine the approximate package and which ones are related (for example #41236 from @rc-component/trigger, #15930 via @types/react). Then check the version release status of the related package through npm:

    Publish Time

    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.

    Schedule build

    As you 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 create-next-app-antd project as the base (in this way, if something goes wrong with the template project, we can also be detected in advance). Created a mock-project-build.yml CI that executes every half hour, which periodically pulls create-next-app-antd repo to build:

    on:
    workflow_dispatch:
    schedule:
    - cron: '*/30 * * * *'

    Pass --depth=1 to only pull the last commit. Then execute yarn to install dependencies to generate the corresponding yarn.lock file, and finally execute yarn build to build to completely simulate the construction process of a project.

    Every time the build is successful, CI will cache the current yarn.lock file. In this way, if the next build fails, we can easily pull the two files for comparison to troubleshoot the problem. Although actions/cache does not allow cache keys with the same name, it allows restore-keys to get the latest cache, which is very convenient:

    - uses: actions/cache@v3
    with:
    path: ~tmpProj/yarn.lock
    key: primes-${{ runner.os }}-${{ github.run_id }}
    restore-keys: mock-proj-lock-file

    Then monitor the build failure event and compare the yarn.lock file to quickly find out the changed dependencies:

    - name: 🎨 Diff Report
    if: ${{ failure() }}
    run: npx diff-yarn-lock --source=~tmpProj/yarn.lock --target=~tmpProj/yarn.lock.failed

    Diff

    Build List

    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 here.

    Finally

    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.