perf: Remove antd-with-locales import

[kgabryje]

SUMMARY

We were importing a huge package antd-with-locales (over 4MB) just to pick 1 locale for DatePicker from it.
This PR removes that import and lazy loads just the required locale.

BEFORE/AFTER SCREENSHOTS OR ANIMATED GIF

Before:

After:

TESTING INSTRUCTIONS

1. Add a time filter to a dashboard
2. Switch to "Custom frame"
3. Open a date picker
4. Should work like before

ADDITIONAL INFORMATION

• Has associated issue:
• Required feature flags:
• Changes UI
• Includes DB Migration (follow approval process in SIP-59)
  • Migration is atomic, supports rollback & is backwards-compatible
  • Confirm DB migration upgrade and downgrade tested
  • Runtime estimates and downtime expectations provided
• Introduces new feature or API
• Removes existing feature or API

[rusackas]

Loving these! Here are some suggestions (take 'em or leave 'em) that I came up with totally on my own with no help.

Potential concerns:

• There might be a brief moment where the component doesn't render while the locale is being loaded
• Error handling for failed locale imports could be improved

Suggestions for improvement:

• Consider adding a loading state instead of returning null when datePickerLocale is null
• Add error handling for the locale import promise to gracefully handle failed imports
• Consider memoizing the effect dependency array to prevent unnecessary re-runs of the effect

[rusackas]

Potential enhancements on the thread, but I love it. LGTM.

[mistercrunch]

LGTM! Thinking of ways to prevent this, but I can totally see how whoever brought this npm library having no indication of the impact on the bundle.

Let's think about what CI automation we'd like to have in place to alert author/reviewers about bundle size changes. Let me start a discussion thread about it.

[mistercrunch]

Started a GH discussion about preventing bundle size creep using CI here -> #29803

[kgabryje]

Had to bump @testing-library/react - our version had a bug which caused waitForElementToBeRemoved to be flaky

[hainenber]

@kgabryje I think your PR's lockfile has slipped out the required @nx dependencies 👀

This is in the master branch (6 search results with dependencies in node_modules)

This is in your PR's branch (only 2 search results without the ones in node_modules)

[kgabryje]

@kgabryje I think your PR's lockfile has slipped out the required @nx dependencies 👀

Oh that's interesting... I only bumped a tests library. I'll try to regenerate package-lock and see if it helps. Thanks!

[kgabryje]

Looks like it's related to this bug. I generated the package-lock file on my M2 macbook, and only arm64 references were generated. I fixed it by removing package-lock.json AND node_modules before rerunning npm-install

[hainenber]

<off-topic>

Looks like it's related to npm/cli#4828. I generated the package-lock file on my M2 macbook, and only arm64 references were generated. I fixed it by removing package-lock.json AND node_modules before rerunning npm-install

Thanks @kgabryje for going through and find the underlying RC! This seems precarious and I couldn't help but wonder if migrating to yarn could help alleviating this if not going with Lerna downgrade approach. Maybe a little too "overkill" though. Wdyt?

Edit: according to this comment in the linked issue, upgrading to currently latest npm version, v10.8.2, could help with the mitigation 🤔

</off-topic>

[kgabryje]

Edit: according to this comment in the linked issue, upgrading to currently latest npm version, v10.8.2, could help with the mitigation 🤔

I did all that with the latest npm version 🙁 A quick (and a bit dirty) fix might be to nx-linux-x64-gnu as Superset dependency - I noticed that @eschutho had a similar problem in another PR some time ago, so I'm not the only one

[eschutho]

I did all that with the latest npm version 🙁 A quick (and a bit dirty) fix might be to nx-linux-x64-gnu as Superset dependency - I noticed that @eschutho had a similar problem in another PR some time ago, so I'm not the only one

The missing optional dependency should be fixed in @mistercrunch's PR, but this package by default will only put into the lockfile the required optional dependencies per the machine that was used to build the lockfile. The docker image recreates the package-lock file, but this may be an issue in the future with pypi or official release tarballs.

-- edit --
I just looked at the package-lock file and all the OSs are included for @nx as optional.