-
-
Notifications
You must be signed in to change notification settings - Fork 1.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: replace framer-motion with motion #4265
base: canary
Are you sure you want to change the base?
Conversation
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
|
@simPod is attempting to deploy a commit to the NextUI Inc Team on Vercel. A member of the Team first needs to authorize it. |
WalkthroughThe pull request involves a comprehensive update across multiple components and documentation files, primarily transitioning from the Changes
Possibly related PRs
Suggested labels
Suggested reviewers
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
Documentation and Community
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 9
🧹 Outside diff range and nitpick comments (18)
packages/utilities/framer-utils/package.json (1)
39-39
: Consider renaming the package for consistency.The package is still named
@nextui-org/framer-utils
but now depends on themotion
package. This might be confusing for users. Consider renaming it to@nextui-org/motion-utils
or similar to maintain consistency with the new dependency.packages/components/ripple/src/ripple.tsx (1)
1-1
: Document breaking changes in release notesThis PR introduces a breaking change by replacing framer-motion with motion. To ensure a smooth migration:
- Update the release notes to clearly indicate this is a breaking change
- Document the minimum required version of motion (11.11.12)
- Provide migration steps for users:
- Remove framer-motion
- Install motion@^11.11.12
- Update imports from 'framer-motion' to 'motion/react'
Consider creating a migration guide in the documentation to help users transition from framer-motion to motion.
packages/components/tabs/package.json (1)
39-39
: Version constraints are consistent with other packagesThe motion package version constraints match those in other package.json files:
- peerDependencies:
">=11.11.12 || >=12.0.0-alpha.1"
- devDependencies:
"11.11.12"
Consider adding a note in the changelog about this dependency change, as it affects multiple packages and requires users to install the new motion package.
Also applies to: 62-62
packages/components/accordion/package.json (1)
45-45
: Consider providing migration guide for usersSince this change affects multiple packages and requires users to switch from framer-motion to motion, consider:
- Adding a migration guide in the documentation
- Including code examples for updating imports
- Documenting any API differences between framer-motion and motion
Would you like me to help draft a migration guide for the documentation?
Also applies to: 74-74
packages/components/navbar/src/navbar-menu.tsx (1)
4-4
: Update import documentationThe import has been correctly updated to use motion/react, but the documentation still references framer-motion.
Update the documentation in the
motionProps
interface:/** - * The props to modify the framer motion animation. Use the `variants` API to create your own animation. + * The props to modify the motion animation. Use the `variants` API to create your own animation. */apps/docs/content/docs/frameworks/vite.mdx (1)
Line range hint
11-11
: Update requirements section for consistencyThe requirements section still mentions "Framer Motion 11.9" which should be updated to reflect the new motion package.
-- [Framer Motion 11.9](https://www.framer.com/motion/) or later ++ [Motion 11.9](https://www.framer.com/motion/) or laterapps/docs/content/docs/frameworks/remix.mdx (1)
Line range hint
10-10
: Update requirements section for consistencyThe requirements section still mentions "Framer Motion 11.9" which should be updated to reflect the new motion package.
-- [Framer Motion 11.9](https://www.framer.com/motion/) or later ++ [Motion 11.9](https://www.framer.com/motion/) or laterpackages/components/date-picker/src/date-picker.tsx (2)
10-10
: Consider documenting breaking changeThe switch from
framer-motion
tomotion/react
forAnimatePresence
might be a breaking change for users who:
- Have explicit dependencies on framer-motion
- Use custom animations that rely on framer-motion specific features
Consider:
- Adding a migration guide in the changelog
- Updating the package.json peer dependencies
Would you like help drafting the migration guide and updating the peer dependencies?
Line range hint
34-37
: Overall recommendations for the migrationTo ensure a smooth transition from framer-motion to motion:
- Update all documentation to reflect the new package name and version requirements
- Add a migration guide in the changelog
- Update peer dependencies in package.json
- Consider adding a codemod to help users migrate their codebase
Would you like assistance with any of these tasks?
packages/core/system/src/provider.tsx (1)
Line range hint
14-24
: Update JSDoc comment to reference motion instead of framer-motionThe JSDoc comment still references framer-motion in the description of
skipFramerMotionAnimations
. This should be updated to reflect the new motion library.- * Controls whether `framer-motion` animations are skipped within the application. - * This property is automatically enabled (`true`) when the `disableAnimation` prop is set to `true`, - * effectively skipping all `framer-motion` animations. To retain `framer-motion` animations while + * Controls whether `motion` animations are skipped within the application. + * This property is automatically enabled (`true`) when the `disableAnimation` prop is set to `true`, + * effectively skipping all `motion` animations. To retain `motion` animations whilepackages/components/accordion/src/accordion-item.tsx (1)
Line range hint
1-100
: Consider documenting this as a breaking changeSince this change requires users to install the
motion
package (v2.7+) instead offramer-motion
, this should be documented as a breaking change in the changelog.packages/components/modal/src/modal-content.tsx (1)
Line range hint
1-150
: Add motion package to peer dependenciesSince the component now depends on the motion package, it should be added to the peer dependencies in package.json with the correct version range (>=2.7.0).
packages/components/tabs/src/tab.tsx (1)
12-12
: Consider documenting the migration requirementsSince this is a significant change from framer-motion to motion/react, we should:
- Document the minimum required version (2.7+) in the package.json
- Update the changelog to reflect this change
- Consider adding a migration guide for users
This change might be considered a breaking change as it requires users to install a different package.
apps/docs/components/sandpack/use-sandpack.ts (1)
146-146
: Remove commented out codeThe commented out section contains an older version (11.11.12) of the motion dependency. This should be removed to avoid confusion.
- // "motion": "11.11.12",
apps/docs/content/docs/api-references/nextui-provider.mdx (1)
147-149
: Fix grammatical issues in disableAnimation descriptionThe description has some grammatical issues. Consider this revision:
-Disables animations globally. This will also avoid `motion` features to be loaded in the bundle which can potentially reduce the bundle size. +Disables animations globally. This will also prevent `motion` features from being loaded in the bundle, which can potentially reduce the bundle size.🧰 Tools
🪛 LanguageTool
[uncategorized] ~147-~147: This verb may not be in the correct form. Consider using a different form for this context.
Context: ...is will also avoidmotion
features to be loaded in the bundle which can potentia...(AI_EN_LECTOR_REPLACEMENT_VERB_FORM)
[uncategorized] ~147-~147: A comma might be missing here.
Context: ...dmotion
features to be loaded in the bundle which can potentially reduce the bundle...(AI_EN_LECTOR_MISSING_PUNCTUATION_COMMA)
apps/docs/content/docs/guide/upgrade-to-v2.mdx (1)
39-41
: Ensure consistent package installation instructionsThe installation commands for
motion
appear in three different sections. Consider consolidating or cross-referencing these sections to maintain consistency and avoid confusion.Consider adding a note explaining the relationship between
framer-motion
andmotion
packages to help users understand the transition.Also applies to: 164-166, 269-271
apps/docs/content/docs/frameworks/nextjs.mdx (2)
24-24
: Fix grammatical issueAdd a comma after "By default" for better readability.
-By default it uses Server Components. +By default, it uses Server Components.🧰 Tools
🪛 LanguageTool
[uncategorized] ~24-~24: Did you mean: “By default,”?
Context: ...duces a newapp/
directory structure. By default it uses Server Components. As NextUI co...(BY_DEFAULT_COMMA)
173-173
: Improve documentation styleConsider varying the phrasing to avoid repetition of "Then you need to add". Some alternatives:
- "Afterward, add"
- "Next, include"
- "Subsequently, add"
Also applies to: 419-419
🧰 Tools
🪛 LanguageTool
[style] ~173-~173: You have already used this phrasing in nearby sentences. Consider replacing it to add variety to your writing.
Context: ...xtjs) to install Tailwind CSS. Then you need to add the following code to your `tailwin...(REP_NEED_TO_VB)
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
⛔ Files ignored due to path filters (1)
pnpm-lock.yaml
is excluded by!**/pnpm-lock.yaml
📒 Files selected for processing (68)
apps/docs/components/blog-post.tsx
(1 hunks)apps/docs/components/blog/video-in-view.tsx
(1 hunks)apps/docs/components/docs/components/code-demo/code-demo.tsx
(1 hunks)apps/docs/components/docs/components/code-demo/window-resizer.tsx
(1 hunks)apps/docs/components/marketing/a11y-otb.tsx
(1 hunks)apps/docs/components/navbar.tsx
(1 hunks)apps/docs/components/sandpack/use-sandpack.ts
(2 hunks)apps/docs/config/search-meta.json
(2 hunks)apps/docs/content/docs/api-references/nextui-provider.mdx
(7 hunks)apps/docs/content/docs/frameworks/astro.mdx
(2 hunks)apps/docs/content/docs/frameworks/nextjs.mdx
(10 hunks)apps/docs/content/docs/frameworks/remix.mdx
(2 hunks)apps/docs/content/docs/frameworks/vite.mdx
(2 hunks)apps/docs/content/docs/guide/installation.mdx
(4 hunks)apps/docs/content/docs/guide/upgrade-to-v2.mdx
(9 hunks)apps/docs/package.json
(1 hunks)packages/components/accordion/package.json
(2 hunks)packages/components/accordion/src/accordion-item.tsx
(1 hunks)packages/components/accordion/src/accordion.tsx
(1 hunks)packages/components/accordion/src/base/accordion-item-base.tsx
(1 hunks)packages/components/autocomplete/package.json
(2 hunks)packages/components/autocomplete/src/autocomplete.tsx
(1 hunks)packages/components/button/package.json
(2 hunks)packages/components/calendar/package.json
(2 hunks)packages/components/calendar/src/calendar-base.tsx
(1 hunks)packages/components/calendar/src/calendar-header.tsx
(1 hunks)packages/components/calendar/src/calendar-month.tsx
(1 hunks)packages/components/calendar/src/calendar-transitions.ts
(1 hunks)packages/components/card/package.json
(2 hunks)packages/components/date-picker/package.json
(2 hunks)packages/components/date-picker/src/date-picker.tsx
(1 hunks)packages/components/date-picker/src/date-range-picker.tsx
(1 hunks)packages/components/dropdown/package.json
(2 hunks)packages/components/modal/package.json
(2 hunks)packages/components/modal/src/modal-content.tsx
(1 hunks)packages/components/modal/src/modal.tsx
(1 hunks)packages/components/modal/src/use-modal.ts
(1 hunks)packages/components/navbar/package.json
(2 hunks)packages/components/navbar/src/navbar-menu-transitions.ts
(1 hunks)packages/components/navbar/src/navbar-menu.tsx
(1 hunks)packages/components/navbar/src/navbar-transitions.ts
(1 hunks)packages/components/navbar/src/navbar.tsx
(1 hunks)packages/components/navbar/src/use-navbar.ts
(1 hunks)packages/components/popover/package.json
(2 hunks)packages/components/popover/src/free-solo-popover.tsx
(1 hunks)packages/components/popover/src/popover-content.tsx
(1 hunks)packages/components/popover/src/popover.tsx
(1 hunks)packages/components/popover/src/use-popover.ts
(1 hunks)packages/components/ripple/package.json
(2 hunks)packages/components/ripple/src/ripple.tsx
(1 hunks)packages/components/select/package.json
(2 hunks)packages/components/select/src/select.tsx
(1 hunks)packages/components/snippet/package.json
(2 hunks)packages/components/tabs/package.json
(3 hunks)packages/components/tabs/src/tab.tsx
(1 hunks)packages/components/tabs/src/tabs.tsx
(1 hunks)packages/components/tabs/src/use-tabs.ts
(1 hunks)packages/components/tooltip/package.json
(2 hunks)packages/components/tooltip/src/tooltip.tsx
(1 hunks)packages/components/tooltip/src/use-tooltip.ts
(1 hunks)packages/core/react/package.json
(1 hunks)packages/core/system/package.json
(1 hunks)packages/core/system/src/provider.tsx
(1 hunks)packages/utilities/dom-animation/package.json
(1 hunks)packages/utilities/dom-animation/src/index.ts
(1 hunks)packages/utilities/framer-utils/package.json
(2 hunks)packages/utilities/framer-utils/src/resizable-panel.tsx
(1 hunks)packages/utilities/framer-utils/src/transition-utils.ts
(1 hunks)
✅ Files skipped from review due to trivial changes (7)
- packages/components/accordion/src/base/accordion-item-base.tsx
- packages/components/navbar/src/navbar-menu-transitions.ts
- packages/components/calendar/src/calendar-transitions.ts
- packages/components/navbar/src/navbar-transitions.ts
- packages/utilities/dom-animation/src/index.ts
- packages/components/calendar/src/calendar-header.tsx
- packages/components/tabs/src/use-tabs.ts
🧰 Additional context used
🪛 LanguageTool
apps/docs/content/docs/frameworks/remix.mdx
[style] ~52-~52: You have already used this phrasing in nearby sentences. Consider replacing it to add variety to your writing.
Context: ...emix) to install Tailwind CSS. Then you need to add the following code to your `tailwin...
(REP_NEED_TO_VB)
apps/docs/content/docs/frameworks/vite.mdx
[style] ~53-~53: You have already used this phrasing in nearby sentences. Consider replacing it to add variety to your writing.
Context: ...eact) to install Tailwind CSS. Then you need to add the following code to your `tailwin...
(REP_NEED_TO_VB)
apps/docs/content/docs/api-references/nextui-provider.mdx
[uncategorized] ~147-~147: This verb may not be in the correct form. Consider using a different form for this context.
Context: ...is will also avoid motion
features to be loaded in the bundle which can potentia...
(AI_EN_LECTOR_REPLACEMENT_VERB_FORM)
[uncategorized] ~147-~147: A comma might be missing here.
Context: ...d motion
features to be loaded in the bundle which can potentially reduce the bundle...
(AI_EN_LECTOR_MISSING_PUNCTUATION_COMMA)
apps/docs/content/docs/frameworks/astro.mdx
[style] ~58-~58: You have already used this phrasing in nearby sentences. Consider replacing it to add variety to your writing.
Context: ...stro) to install Tailwind CSS. Then you need to add the following code to your `tailwin...
(REP_NEED_TO_VB)
apps/docs/content/docs/frameworks/nextjs.mdx
[uncategorized] ~24-~24: Did you mean: “By default,”?
Context: ...duces a new app/
directory structure. By default it uses Server Components. As NextUI co...
(BY_DEFAULT_COMMA)
[style] ~173-~173: You have already used this phrasing in nearby sentences. Consider replacing it to add variety to your writing.
Context: ...xtjs) to install Tailwind CSS. Then you need to add the following code to your `tailwin...
(REP_NEED_TO_VB)
[style] ~419-~419: You have already used this phrasing in nearby sentences. Consider replacing it to add variety to your writing.
Context: ...xtjs) to install Tailwind CSS. Then you need to add the following code to your `tailwin...
(REP_NEED_TO_VB)
apps/docs/content/docs/guide/upgrade-to-v2.mdx
[uncategorized] ~26-~26: Did you mean: “By default,”?
Context: ...duces a new app/
directory structure. By default it uses Server Components. As NextUI co...
(BY_DEFAULT_COMMA)
[style] ~62-~62: You have already used this phrasing in nearby sentences. Consider replacing it to add variety to your writing.
Context: ...xtjs) to install Tailwind CSS. Then you need to add the following code to your `tailwin...
(REP_NEED_TO_VB)
[style] ~187-~187: You have already used this phrasing in nearby sentences. Consider replacing it to add variety to your writing.
Context: ...xtjs) to install Tailwind CSS. Then you need to add the following code to your `tailwin...
(REP_NEED_TO_VB)
[uncategorized] ~269-~269: Did you mean “I”?
Context: ...ageManagers commands={{ npm: 'npm i motion', yarn: 'yarn add motion', ...
(I_LOWERCASE_PREMIUM)
🔇 Additional comments (58)
packages/core/system/package.json (1)
37-37
: Verify motion dependency configuration across the project
Let's ensure the motion dependency is properly configured across the workspace.
Also applies to: 43-43
✅ Verification successful
Motion dependency configuration is consistent across the project
The motion dependency is properly configured across the workspace with:
- Consistent version
11.11.12
in devDependencies for components and utilities - Consistent peer dependency range
>=11.11.12 || >=12.0.0-alpha.1
across packages - Only docs app uses a slightly newer version
11.13.1
which is compatible with the peer dependency range
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check motion dependency configuration across the workspace
# Check if motion is listed in the root package.json
echo "Checking root package.json for motion dependency:"
jq '.dependencies.motion, .devDependencies.motion' package.json
# Find all package.json files that reference motion
echo -e "\nChecking all package.json files for motion dependency:"
fd package.json --type f --exec sh -c 'echo "=== {} ==="; jq "select(.dependencies.motion != null or .devDependencies.motion != null or .peerDependencies.motion != null) | {name: .name, dependencies: .dependencies.motion, devDependencies: .devDependencies.motion, peerDependencies: .peerDependencies.motion}" {}'
# Check for any remaining framer-motion references
echo -e "\nChecking for remaining framer-motion references:"
fd package.json --type f --exec sh -c 'echo "=== {} ==="; jq "select(.dependencies.[\"framer-motion\"] != null or .devDependencies.[\"framer-motion\"] != null or .peerDependencies.[\"framer-motion\"] != null) | {name: .name, dependencies: .dependencies.[\"framer-motion\"], devDependencies: .devDependencies.[\"framer-motion\"], peerDependencies: .peerDependencies.[\"framer-motion\"]}" {}'
Length of output: 57245
Script:
#!/bin/bash
# Let's try a simpler approach to check motion dependency configuration
# Check for motion dependencies across all package.json files
echo "=== Checking motion dependencies ==="
fd package.json --type f --exec grep -l "\"motion\":" {} \; | while read -r file; do
echo -e "\n=== $file ==="
grep "\"motion\":" "$file" -A 1 -B 1
done
Length of output: 8011
packages/components/modal/src/modal.tsx (1)
2-2
: LGTM! Verify motion dependency.
The import change from framer-motion to motion/react is correct. The AnimatePresence API remains compatible.
packages/utilities/framer-utils/src/resizable-panel.tsx (1)
4-4
: LGTM! Verify motion APIs compatibility.
The import change for domAnimation, LazyMotion, and m components is correct. The APIs remain compatible.
✅ Verification successful
Import statement is correctly using valid APIs from motion/react
The verification confirms that all imported components (domAnimation
, LazyMotion
, and m
) are being used consistently across the codebase from the "motion/react" package. Multiple files demonstrate the same import pattern, confirming API compatibility.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Verify the imported APIs exist in motion package
ast-grep --pattern 'import {$$$} from "motion/react"' | grep -E 'domAnimation|LazyMotion|m'
Length of output: 3595
packages/utilities/dom-animation/package.json (2)
37-37
: Verify version constraints compatibility.
The peer dependency version constraint >=11.11.12 || >=12.0.0-alpha.1
needs verification to ensure it covers all required features from framer-motion.
✅ Verification successful
Based on the shell script results, I can now verify the version constraints. The output shows:
- The latest version of
motion
package is 11.13.1 - The version constraint
>=11.11.12 || >=12.0.0-alpha.1
covers:- All versions from 11.11.12 onwards (including latest 11.13.1)
- Any future 12.x alpha/beta/stable releases
Let me verify the codebase usage:
Let me check the actual motion usage in the codebase:
Let me check the actual implementation to understand the motion usage:
Version constraints are appropriate for the package's usage
The version constraint >=11.11.12 || >=12.0.0-alpha.1
is well-suited for this package because:
- The package simply re-exports the
domAnimation
feature frommotion/react
- The constraint ensures compatibility with both current stable (11.x) and future (12.x) versions
- The minimum version 11.11.12 matches the devDependency version used for development/testing
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check for motion package release notes or changelog
curl -s "https://registry.npmjs.org/motion" | jq -r '."dist-tags",.time' 2>/dev/null
# Look for potential breaking changes in the codebase
rg -g '!node_modules' -g '!dist' "framer-motion" -A 5
Length of output: 83389
Script:
# Look for motion imports and usage
rg -g '!node_modules' -g '!dist' -g '*.{ts,tsx,js,jsx}' "from ['\"]motion['\"]" -A 2
# Check package.json files for motion dependencies
fd "package.json" -x grep -l "motion"
Length of output: 963
Script:
# Check motion imports and usage patterns
rg -g '!node_modules' -g '!dist' -g '*.{ts,tsx,js,jsx}' "from ['\"]@?motion['\"]|from ['\"]framer-motion['\"]" -B 1 -A 3
# Check the specific package's dependencies
cat packages/utilities/dom-animation/package.json
Length of output: 1295
Script:
# Check the source code of dom-animation package
fd . packages/utilities/dom-animation/src -t f -x cat {}
# Look for motion-related imports and usage in the codebase
rg -g '!node_modules' -g '!dist' -g '*.{ts,tsx,js,jsx}' "from ['\"]@nextui-org/dom-animation['\"]" -B 1 -A 3
Length of output: 248
37-37
:
Breaking Change: Users must install motion package.
This change requires users to install the motion package (>=11.11.12) instead of framer-motion. This should be clearly documented in the migration guide.
Also applies to: 41-41
packages/components/popover/src/popover.tsx (1)
4-4
: LGTM! Verify animation behavior remains consistent.
The import change from framer-motion
to motion/react
is correct. Since this is a core animation component, we should ensure the animation behavior remains unchanged.
✅ Verification successful
Based on the gathered information, I can now provide a final response. The code shows that:
- The import change from 'framer-motion' to 'motion/react' for AnimatePresence is correct
- AnimatePresence is used correctly in the popover component for mounting/unmounting animations
- The tests don't explicitly test animations but cover the component's core functionality
- No animation-specific behavior is broken by this change
LGTM! Import path change is safe and maintains animation functionality.
The change from framer-motion
to motion/react
is a valid refactor as:
- The AnimatePresence API remains the same
- The component's animation wrapper implementation is unchanged
- All tests pass without animation-related issues
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check for any other framer-motion imports in related files
# and verify AnimatePresence usage consistency
# Check for any remaining framer-motion imports
rg -l 'framer-motion' packages/components/popover/
# Check AnimatePresence usage pattern
ast-grep --pattern 'AnimatePresence>{$$$}</AnimatePresence>' packages/components/popover/
Length of output: 183
Script:
#!/bin/bash
# Let's check the CHANGELOG.md content and AnimatePresence usage more thoroughly
cat packages/components/popover/CHANGELOG.md
# Check actual AnimatePresence usage in the source files
rg -A 5 "AnimatePresence" packages/components/popover/src/
# Check if there are any test files that might be affected
fd "test|spec" packages/components/popover/
Length of output: 38139
Script:
#!/bin/bash
# Let's check the test file to see how AnimatePresence is being used in tests
cat packages/components/popover/__tests__/popover.test.tsx
# Let's also check if there are any animation-related tests
rg -A 3 "animation|motion" packages/components/popover/__tests__/popover.test.tsx
Length of output: 10603
packages/utilities/framer-utils/package.json (1)
39-39
: Verify version compatibility with other packages.
The version requirements have been updated to >=11.11.12 || >=12.0.0-alpha.1
. Let's verify this version is compatible with other packages in the monorepo.
Also applies to: 50-50
✅ Verification successful
Motion version requirements are consistent across the monorepo
The version requirements >=11.11.12 || >=12.0.0-alpha.1
are compatible across all packages in the monorepo. The scan shows:
- Most packages use
11.11.12
as a direct dependency and>=11.11.12 || >=12.0.0-alpha.1
as a peer dependency @nextui-org/react
(core/react) uses only the peer dependency>=11.11.12 || >=12.0.0-alpha.1
- The docs app uses a fixed version
11.13.1
which satisfies the version requirements
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check motion dependency versions across the monorepo
# Find all package.json files and grep for motion versions
fd package.json -x grep -l '"motion"' {} \; -x jq -r '.dependencies.motion + " " + .devDependencies.motion + " " + .peerDependencies.motion' {}
Length of output: 1768
packages/components/ripple/package.json (1)
39-39
: LGTM! Version requirements are consistent.
The version requirements for the motion
package match those in other packages, maintaining consistency across the monorepo.
Also applies to: 52-52
packages/components/navbar/src/navbar.tsx (1)
3-3
: Verify motion features compatibility with LazyMotion
The import change looks correct, but we should verify that all required motion features are still available through the domAnimation import.
✅ Verification successful
Import change from 'framer-motion' to 'motion/react' is correctly implemented
The verification shows that:
- The import change is consistent across the entire codebase, with all motion-related imports using the new 'motion/react' path
- The LazyMotion component is properly used with domAnimation from '@nextui-org/dom-animation'
- The implementation follows the same pattern in other components (accordion, modal, popover, etc.)
- All required motion features (LazyMotion, m, AnimatePresence) are available and working through the new import path
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check if any other motion-specific features are used in the codebase
rg --type typescript "import.*motion" -g '!node_modules' -A 2
Length of output: 98
Script:
#!/bin/bash
# Check motion imports and their usage patterns in the codebase
rg "import.*motion" --type ts --type tsx -A 2
# Check for motion-specific features and animations
rg "LazyMotion|domAnimation|AnimatePresence|motion\." --type ts --type tsx
# Check the specific file content
cat "packages/components/navbar/src/navbar.tsx"
Length of output: 1865
Script:
#!/bin/bash
# Search for files using fd and then use ripgrep
fd -e ts -e tsx | xargs rg "import.*motion|from.*motion"
# Check the dom-animation implementation
fd -g "*dom-animation*" --type f --full-path
# Check for motion-related features usage
fd -e ts -e tsx | xargs rg "LazyMotion|domAnimation|AnimatePresence|motion\."
Length of output: 14367
packages/components/accordion/src/accordion.tsx (1)
2-2
: Verify LayoutGroup behavior remains unchanged
While the import path is updated correctly, we should verify that the LayoutGroup component from motion/react behaves identically to the one from framer-motion, especially regarding animation handling.
✅ Verification successful
LayoutGroup import change is part of a consistent migration pattern
The codebase shows a systematic migration from 'framer-motion' to 'motion/react', with LayoutGroup being used consistently in both accordion and tabs components. The usage pattern remains identical:
- In accordion: Wraps content with
<LayoutGroup>{content}</LayoutGroup>
when animation is enabled - In tabs: Wraps tabs with
<LayoutGroup id={layoutId}>{tabs}</LayoutGroup>
when layout group is enabled
The migration appears to be a deliberate architectural change across the entire codebase, as evidenced by numerous other motion-related imports (AnimatePresence, LazyMotion, etc.) all using the 'motion/react' path.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check for LayoutGroup usage patterns
rg --type typescript "LayoutGroup" -B 2 -A 2 -g '!node_modules'
# Check for any motion-specific props or configurations
rg --type typescript "LayoutGroup.*props" -g '!node_modules'
Length of output: 196
Script:
#!/bin/bash
# Check for LayoutGroup usage patterns without typescript type
rg "LayoutGroup" -B 2 -A 2
# Search for motion/react imports
rg "from ['\"]motion/react['\"]"
# Search for framer-motion imports for comparison
rg "from ['\"]framer-motion['\"]"
Length of output: 5802
packages/components/button/package.json (1)
39-39
: Verify version requirements and breaking changes
The transition from framer-motion to motion with updated version requirements (>=11.11.12) might be a breaking change. According to the motion blog, motion is a drop-in replacement for framer-motion, but the version bump from 11.5.6 to 11.11.12 needs verification.
Consider documenting this change in the migration guide, including:
- Instructions for users to update their dependencies
- Any breaking changes or API modifications
- Minimum version requirements
Also applies to: 61-61
✅ Verification successful
Version change appears to be part of a coordinated update
Based on the search results, this change from framer-motion to motion is part of a broader React packages upgrade across the codebase. The version requirement (>=11.11.12) is consistently applied across multiple components and utilities, suggesting a coordinated update rather than an isolated change. The package is also actively maintained with versions 11.11.12 through 11.11.17 available.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check for breaking changes between framer-motion 11.5.6 and motion 11.11.12
# Get the changelog or release notes
gh api repos/framer/motion/releases | jq -r '.[].body' | grep -B2 -A2 "BREAKING CHANGE"
# Check if motion package is published and its version history
curl -s https://registry.npmjs.org/motion | jq '.versions | keys[]' | grep "11.11"
Length of output: 238
Script:
#!/bin/bash
# Let's check the actual changes in the package.json files
rg -U "\"motion\":|\"framer-motion\":" --type json -A 2 -B 2
# Check for any migration guides or documentation
fd -e md -e mdx | xargs rg -i "migration|upgrade|breaking.?change" -C 2
# Check for actual usage of motion/framer-motion in the codebase
rg -l "from ['\"](framer-)?motion['\"]" --type-add 'ts:*.{ts,tsx}' --type ts
Length of output: 79908
Script:
#!/bin/bash
# Let's check the previous version of motion/framer-motion in package.json files
git log -p packages/components/button/package.json | grep -A 5 -B 5 "\"motion\"\|\"framer-motion\""
# Let's also check for any breaking changes documentation
fd -e md -e mdx | xargs rg -i "breaking.?changes?.*(motion|framer)" -C 2
Length of output: 74
packages/components/tooltip/package.json (1)
39-39
: Review dependency on @nextui-org/framer-utils
While transitioning from framer-motion to motion, noticed that this package still depends on @nextui-org/framer-utils
. This might need to be reviewed to ensure consistency with the migration.
Also applies to: 63-63
✅ Verification successful
Let me gather more information about the framer-utils package and its usage in the tooltip component.
Keep the dependency on @nextui-org/framer-utils
The framer-utils package has been updated to support the new motion
package as a peer dependency. It provides essential transition utilities and animations that are still being used by the tooltip component (specifically the TRANSITION_VARIANTS
). The package is correctly maintained and compatible with the migration from framer-motion to motion.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check the usage of framer-utils in the codebase
# Check for framer-utils package references
rg -l "framer-utils"
# Check for specific imports from framer-utils
ast-grep --pattern 'import { $_ } from "@nextui-org/framer-utils"'
Length of output: 5258
Script:
#!/bin/bash
# Check the content of framer-utils package to understand its purpose
cat packages/utilities/framer-utils/package.json
# Check the specific usage in tooltip component
cat packages/components/tooltip/src/tooltip.tsx
# Check if there are any motion-specific utilities in framer-utils
cat packages/utilities/framer-utils/src/*.ts
Length of output: 8348
packages/components/card/package.json (1)
39-39
: Version requirements are consistent across packages
The motion dependency version requirements (>=11.11.12) align with other packages in the codebase, which is good for maintaining consistency.
Also applies to: 63-63
✅ Verification successful
Motion dependency version requirements are consistent across packages
All NextUI packages have the same version requirement for the motion dependency: >=11.11.12 || >=12.0.0-alpha.1
, except for the docs package which uses a fixed version 11.13.1
. This is expected as the docs package is a consumer of the components rather than a library package.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Verify consistency of motion dependency across all package.json files
# Find all package.json files and check motion versions
fd package.json | xargs jq -r '. | select(.dependencies.motion or .devDependencies.motion or .peerDependencies.motion) | "\(.name): \(.peerDependencies.motion // .devDependencies.motion // .dependencies.motion)"'
Length of output: 1237
packages/components/dropdown/package.json (1)
39-39
: Verify motion library version compatibility
The change from framer-motion to motion requires careful consideration:
- The peer dependency version
>=11.11.12 || >=12.0.0-alpha.1
aligns with the motion library's versioning - The dev dependency version
11.11.12
is fixed, which is good for development stability
Consider documenting this as a breaking change in the migration guide, as users will need to:
- Remove framer-motion
- Install motion@^11.11.12
Also applies to: 65-65
✅ Verification successful
Motion library version constraints are consistent across the monorepo
The version constraints are correctly aligned across all packages:
- All packages using motion have the same peer dependency version
>=11.11.12 || >=12.0.0-alpha.1
- All packages have the same fixed dev dependency version
11.11.12
- The main package
@nextui-org/react
correctly specifies the peer dependency without a dev dependency
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check if other packages in the monorepo have consistent motion versions
fd -e json package.json | xargs jq -r 'select(.dependencies.motion or .devDependencies.motion or .peerDependencies.motion) | "\(.name): dev=\(.devDependencies.motion) peer=\(.peerDependencies.motion)"'
Length of output: 1575
packages/components/tabs/src/tabs.tsx (1)
2-2
: Verify LayoutGroup API compatibility
The import change from framer-motion to motion/react looks correct. The LayoutGroup component is used appropriately for animation grouping.
✅ Verification successful
Let me check the CHANGELOG.md to understand the context of the framer-motion reference.
Based on the search results, I can verify that the import change from framer-motion
to motion/react
is consistent with the codebase's pattern. The LayoutGroup
component is imported from motion/react
in both the tabs and accordion components, and it's used in the same way. The API usage appears to be identical across the codebase.
Import change is consistent with codebase patterns
The change from framer-motion
to motion/react
for the LayoutGroup
import is correct and follows the established pattern across the codebase. The reference in CHANGELOG.md is historical and doesn't affect the current implementation.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check for any other framer-motion imports that might have been missed
rg -l "framer-motion" packages/components/tabs/
Length of output: 85
Script:
#!/bin/bash
# Check the content of CHANGELOG.md
cat packages/components/tabs/CHANGELOG.md
# Check if LayoutGroup is used in the codebase
ast-grep --pattern 'LayoutGroup'
# Check for any other motion/react imports
rg "motion/react"
Length of output: 35156
packages/components/ripple/src/ripple.tsx (1)
3-3
: Verify motion components API compatibility
The changes look correct but require verification of API compatibility:
- HTMLMotionProps type import
- AnimatePresence, m, and LazyMotion components from motion/react
- Animation features used in the component
Consider adding a comment documenting that the animation implementation relies on motion/react features, particularly:
- LazyMotion with domAnimation
- AnimatePresence for exit animations
- m.span for motion components
Also applies to: 6-6
✅ Verification successful
Let me generate additional scripts to verify the API compatibility by checking the actual usage patterns:
Let me run one final check to verify the complete ripple component implementation:
Import changes from framer-motion to motion/react are correctly implemented
The verification confirms that:
- The HTMLMotionProps type is correctly imported and used in the component props interface
- LazyMotion is properly configured with domAnimation from @nextui-org/dom-animation
- AnimatePresence and m.span components are used consistently with the expected motion/react API
- The animation features (scale, opacity, transitions) are implemented using the standard motion API
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check for any remaining framer-motion references
rg -l "framer-motion" packages/components/ripple/
# Check for similar animation patterns across the codebase
ast-grep --pattern 'import {$$$} from "motion/react"'
Length of output: 3647
Script:
#!/bin/bash
# Check HTMLMotionProps usage
ast-grep --pattern 'HTMLMotionProps<$_>'
# Check LazyMotion usage with domAnimation
ast-grep --pattern 'LazyMotion $$$domAnimation$$$'
# Check AnimatePresence and m.span patterns in ripple component
rg -A 5 "<AnimatePresence|<m\." packages/components/ripple/src/ripple.tsx
Length of output: 470
Script:
#!/bin/bash
# Get the full ripple component implementation
cat packages/components/ripple/src/ripple.tsx
# Check if there are any migration guides or documentation
fd -g "*.md" -x grep -l "motion/react" {} \;
Length of output: 2209
packages/components/autocomplete/src/autocomplete.tsx (1)
9-9
: Verify breaking change impact of motion library migration
The import path change from framer-motion
to motion/react
is correct. However, this change might affect consumers who need to install the new motion
package.
Consider documenting this breaking change in the migration guide, instructing users to:
- Install the
motion
package (v2.7 or higher) - Update their import statements from
framer-motion
tomotion/react
✅ Verification successful
Import change from framer-motion to motion/react is part of a broader migration
Based on the codebase analysis, this is a valid change as part of a larger migration from framer-motion
to the new motion
package. The evidence shows:
- Multiple components across the codebase consistently use
motion/react
imports - Several animation-related files (custom-motion.ts) exist in different component directories
- The component correctly uses
AnimatePresence
from the new import path
The change is safe and follows the established pattern in the codebase.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check if there are any other framer-motion imports in the codebase
rg "from ['\"]framer-motion['\"]" --type ts --type tsx
# Check for any potential motion-specific APIs that might have changed
rg "AnimatePresence|motion\." --type ts --type tsx
Length of output: 169
Script:
#!/bin/bash
# Check for framer-motion imports without file type restrictions
rg "from ['\"]framer-motion['\"]"
# Check for motion/react imports
rg "from ['\"]motion/react['\"]"
# Check for AnimatePresence usage
rg "AnimatePresence"
# List all TypeScript and TypeScript React files
fd "\.(ts|tsx)$"
Length of output: 72963
Script:
#!/bin/bash
# Check package.json for dependencies
rg "framer-motion|motion" package.json
# Check for any motion-specific configuration files
fd "motion.*\.(js|ts|json)$"
# Check for motion-specific imports in the component
cat packages/components/autocomplete/src/autocomplete.tsx
Length of output: 2540
packages/components/popover/package.json (1)
39-39
: Verify motion package version compatibility
The version constraints for the motion package are:
- peerDependencies:
">=11.11.12 || >=12.0.0-alpha.1"
- devDependencies:
"11.11.12"
These versions align with the PR objectives, but we should verify consistency across all packages.
Also applies to: 67-67
✅ Verification successful
Motion package versions are consistent across all packages
The version constraints for the motion package are consistent across all NextUI packages:
- All packages use
"11.11.12"
for devDependencies - All packages use
">=11.11.12 || >=12.0.0-alpha.1"
for peerDependencies
The only exceptions are @nextui-org/docs
and @nextui-org/react
which don't have devDependencies for motion, which is expected as they are consumer packages.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check for any inconsistent motion package versions across package.json files
fd package.json | xargs jq -r 'select(.dependencies.motion or .devDependencies.motion or .peerDependencies.motion) | "\(.name): dev=\(.devDependencies.motion // "none") peer=\(.peerDependencies.motion // "none")"'
Length of output: 1587
packages/components/date-picker/package.json (1)
39-39
:
Breaking Change: Package dependency update requires user action
The change from framer-motion to motion is a breaking change that requires users to:
- Remove framer-motion
- Install motion v11.11.12 or higher
This should be clearly documented in the changelog and release notes.
Let's verify the version compatibility:
Also applies to: 69-69
✅ Verification successful
Breaking Change: Package dependency update is consistent across the monorepo
The change from framer-motion to motion is a coordinated breaking change across multiple packages in the monorepo:
- The version requirements (
>=11.11.12 || >=12.0.0-alpha.1
) are consistent across all packages - All packages using motion have both dev dependency (11.11.12) and peer dependency aligned
- The latest stable version of motion (11.13.1) satisfies these requirements
- No deprecation notices found for version 11.11.12
The version constraints are appropriate and well-coordinated across the codebase.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check if the specified motion version is the latest stable
curl -s https://registry.npmjs.org/motion/latest | jq '.version'
# Check for any known issues with motion v11.11.12
curl -s https://registry.npmjs.org/motion | jq '.versions["11.11.12"].deprecated'
Length of output: 163
Script:
#!/bin/bash
# Check if other packages in the monorepo also use motion/framer-motion
fd -e json package.json --exec grep -l "motion[\":]" {}
# Check the current package's dependencies on motion
cat packages/components/date-picker/package.json | jq '.dependencies,.devDependencies,.peerDependencies | select(. != null) | with_entries(select(.key | contains("motion")))'
Length of output: 1151
Script:
#!/bin/bash
# Check the motion dependency specifications in other packages
for f in $(fd -e json package.json); do
echo "=== $f ==="
cat "$f" | jq '.dependencies,.devDependencies,.peerDependencies | select(. != null) | with_entries(select(.key | contains("framer-motion") or .key | contains("motion")))'
done
Length of output: 37033
Script:
#!/bin/bash
# Let's try a simpler approach to check motion dependencies
echo "=== Checking motion version in date-picker package ==="
cat packages/components/date-picker/package.json | grep -A 2 -B 2 "motion"
echo -e "\n=== Checking other packages using motion ==="
for f in $(fd -e json package.json); do
if grep -q "motion" "$f"; then
echo "=== $f ==="
grep -A 2 -B 2 "motion" "$f"
fi
done
Length of output: 19345
packages/components/navbar/package.json (1)
39-39
: Version requirements are consistent with other packages
The motion dependency version requirements align with other packages in the monorepo, which is good for maintaining consistency.
Also applies to: 66-66
packages/components/accordion/package.json (1)
Line range hint 1-79
: Overall Package Migration Strategy
The consistent update of motion dependency across all packages is well-executed. However, this is a breaking change that requires careful handling:
- Update the package's major version following semver
- Document the breaking change in CHANGELOG.md
- Consider adding a codemod to automate the migration
- Update all example code and documentation to use motion instead of framer-motion
Let's verify the impact across the codebase:
✅ Verification successful
Let me gather more information about the actual usage of motion to verify the migration status.
Migration to motion
package is properly implemented
The codebase shows a consistent migration from framer-motion
to motion
:
- All component imports are using the new
motion/react
package - No active imports from
framer-motion
were found - The migration covers all animation-related components (Accordion, Modal, Popover, etc.)
- References to
framer-motion
only appear in CHANGELOG files, which is expected
The breaking change is well-handled as:
- The migration is complete and consistent across all packages
- The
motion
dependency is properly declared in package.json files - The implementation uses the correct new import paths
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check for any remaining framer-motion references
rg -l 'framer-motion'
# Check for existing motion imports to ensure consistency
rg -l 'from ["'\'']motion/'
Length of output: 5744
Script:
#!/bin/bash
# Check actual motion imports and their usage patterns
rg -A 2 'from ["'\'']motion/' --type tsx --type ts
# Check if there are any remaining framer-motion imports
rg -A 2 'from ["'\'']framer-motion' --type tsx --type ts
# Check package.json files for motion dependency
fd package.json --exec grep -l "motion"
Length of output: 1044
Script:
#!/bin/bash
# Check actual motion imports and their usage patterns without file type flags
rg -A 2 'from ["'\'']motion/'
# Check if there are any remaining framer-motion imports
rg -A 2 'from ["'\'']framer-motion'
# Check the version of motion in package.json files
rg '"motion":\s*"[^"]*"' packages/*/package.json
Length of output: 11551
packages/components/modal/package.json (1)
39-39
: Version constraints are consistent
The motion dependency version constraints match across packages, which is good for maintaining consistency:
- peerDependencies: >=11.11.12 || >=12.0.0-alpha.1
- devDependencies: 11.11.12
Also applies to: 70-70
packages/components/navbar/src/navbar-menu.tsx (1)
4-4
: Verify animation behavior compatibility
Need to verify that the animation features from motion/react work identically to framer-motion.
Also applies to: 23-23
✅ Verification successful
Animation features are compatible with framer-motion
Based on the codebase analysis, the animation features from motion/react
are being used consistently across components with the same patterns as framer-motion:
- Using identical animation props (
animate
,initial
,exit
,transition
) - Employing the same components (
AnimatePresence
,LazyMotion
,m
) - Utilizing identical variant patterns for transitions
- Consistent usage of motion props types (
HTMLMotionProps
)
The import change from framer-motion
to motion/react
appears to be a deliberate migration that maintains API compatibility.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for any custom animation variants or motion features that might need verification
rg -l 'variants.*=.*{' | xargs rg -A 5 'variants.*=.*{'
# Search for any motion-specific props that might need compatibility checking
ast-grep --pattern 'motion.$_($$$)'
Length of output: 279
Script:
#!/bin/bash
# Search for animation variants with proper regex escaping
rg "variants.*=.*\{" -A 5
# Search for motion component usage
rg "<motion\." -A 2
rg "<m\." -A 2
# Search for animation-related imports
rg "import.*from.*motion"
rg "import.*from.*framer-motion"
# Search for animation-related props
rg "animate=|transition=|initial=|exit=" -A 2
Length of output: 27601
apps/docs/components/blog-post.tsx (1)
8-8
: Import change looks good, but consider documenting breaking change
The import change from framer-motion
to motion/react
is correct. However, this change requires users to install the motion
package instead of framer-motion
.
Let's verify if this change is consistently applied across the codebase:
✅ Verification successful
Import change is consistently applied across the codebase
The verification shows that all imports are consistently using motion/react
and there are no remaining imports from framer-motion
. The change has been properly implemented across the entire codebase, including components, utilities, and documentation.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check for any remaining framer-motion imports
rg "from ['\"]framer-motion['\"]"
# Check for new motion imports
rg "from ['\"]motion/react['\"]"
Length of output: 4312
packages/components/select/package.json (1)
39-39
: Dependency update looks good, version constraints are appropriate
The migration from framer-motion
to motion
is correctly implemented with appropriate version constraints:
- peerDependencies:
">=11.11.12 || >=12.0.0-alpha.1"
allows flexibility for users - devDependencies: Fixed version
"11.11.12"
ensures consistent development environment
Let's verify version consistency across all package.json files:
Also applies to: 76-76
✅ Verification successful
Version constraints are consistent across all packages
The verification shows that all NextUI packages have consistent version constraints for the motion
dependency:
- All component packages use
>=11.11.12 || >=12.0.0-alpha.1
in their peer dependencies - Only the docs package uses a fixed version
11.13.1
, which is appropriate as it's a consumer application
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check for consistent motion version across all package.json files
fd package.json | xargs jq -r '. | select(.dependencies.motion or .devDependencies.motion or .peerDependencies.motion) | "\(.name): \(.peerDependencies.motion // .devDependencies.motion // .dependencies.motion)"'
Length of output: 1237
packages/components/tooltip/src/tooltip.tsx (1)
3-3
: LGTM! Verify motion/react compatibility
The import change from framer-motion to motion/react is correct. However, let's verify the compatibility with the existing animation setup.
✅ Verification successful
LGTM! The motion/react import is correctly implemented
The import change is verified to be compatible with the existing animation setup. The evidence shows:
- The
domAnimation
is correctly imported from@nextui-org/dom-animation
and used withLazyMotion
- The animation components (
AnimatePresence
,m
,LazyMotion
) frommotion/react
are used consistently across the codebase - The implementation follows the same pattern used in other components that use animations
- The dynamic import of
domAnimation
ensures proper code-splitting and performance optimization
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Verify that the domAnimation import is compatible with motion/react
# and that all animation-related imports are consistent
# Check for any remaining framer-motion imports
rg "framer-motion" --type ts --type tsx
# Check for consistency in motion imports
rg "from ['\"]motion/react['\"]" --type ts --type tsx
Length of output: 155
Script:
#!/bin/bash
# Search for framer-motion imports without file type restrictions
rg "framer-motion"
# Search for motion/react imports without file type restrictions
rg "from ['\"]motion/react['\"]"
# Look for animation-related files and imports
fd "animation|motion" --type f
# Check the content of the tooltip component for animation setup
cat packages/components/tooltip/src/tooltip.tsx
Length of output: 57526
Script:
#!/bin/bash
# Check the content of the dom-animation module to verify compatibility
cat packages/utilities/dom-animation/src/index.ts
# Check for any motion/react imports in the codebase to verify consistency
rg "from ['\"]motion/react['\"]" -A 1 -B 1
# Look for any animation-related imports and usage
rg "domAnimation|LazyMotion" -A 1 -B 1
Length of output: 25249
apps/docs/content/docs/frameworks/vite.mdx (1)
29-32
: LGTM! Package installation commands updated correctly
The package installation commands have been correctly updated to use 'motion' instead of 'framer-motion'.
apps/docs/content/docs/frameworks/remix.mdx (1)
28-31
: LGTM! Package installation commands updated correctly
The package installation commands have been correctly updated to use 'motion' instead of 'framer-motion'.
packages/components/popover/src/popover-content.tsx (1)
2-2
: Verify motion API compatibility
The imports have been updated to use motion/react
. Please ensure that:
- The
HTMLMotionProps
type from motion/react maintains API compatibility - The
m
andLazyMotion
components from motion/react behave the same as their framer-motion counterparts
Also applies to: 7-7
✅ Verification successful
Let me gather more information about the motion API usage in the codebase.
Let me check one more thing to verify the motion package's configuration.
Motion API compatibility is maintained
Based on the codebase analysis, the migration from framer-motion
to motion/react
maintains API compatibility:
- The
HTMLMotionProps
type is consistently used across components with the same type signature - The motion components (
m
,LazyMotion
,AnimatePresence
) are used with identical patterns and features - All components using motion features properly initialize
LazyMotion
withdomAnimation
ordomMax
- The migration appears to be part of a planned update mentioned in the changelog
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for any motion-specific prop types or components that might need attention
rg -l "HTMLMotionProps|LazyMotion|AnimatePresence" | xargs rg "framer-motion"
Length of output: 2161
Script:
#!/bin/bash
# Search for HTMLMotionProps usage in the codebase
ast-grep --pattern 'HTMLMotionProps'
# Search for motion component usage patterns
ast-grep --pattern 'm.$_'
# Search for LazyMotion usage
ast-grep --pattern 'LazyMotion'
# Check package.json for motion dependencies
cat package.json | jq '.dependencies["motion/react"], .dependencies["framer-motion"]'
Length of output: 7446
Script:
#!/bin/bash
# Check package.json files in components directory for motion dependencies
find packages/components -name "package.json" -exec cat {} \; | jq -c 'select(.dependencies != null) | {name: .name, deps: .dependencies | with_entries(select(.key | contains("motion")))}'
# Check if there are any migration guides or documentation
fd -g "*.md" | xargs rg -l "motion/react|framer-motion"
Length of output: 5620
packages/components/calendar/src/calendar-month.tsx (2)
6-6
: Verify motion import path
The import path has been updated from framer-motion to motion/react. This is correct according to the motion library's documentation.
Line range hint 89-102
: Animation behavior remains consistent
The animation implementation using m.tbody
with variants
and animation props remains functionally equivalent to the previous framer-motion implementation.
✅ Verification successful
Let me verify the animation implementation by checking the actual code in the calendar component.
Animation implementation is correctly maintained
The code shows that the animation behavior is indeed functionally equivalent to the previous implementation:
- The component uses
m.tbody
frommotion/react
for animated transitions - The same slide variants and animation props (
animate
,initial
,exit
) are maintained - The animation can be disabled via
disableAnimation
prop, rendering a regulartbody
- The transition configuration in
calendar-transitions.ts
remains consistent with spring animation type
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check for any remaining framer-motion imports in the codebase
rg -l 'framer-motion'
# Check for consistent usage of motion/react
rg -l 'motion/react'
Length of output: 5735
Script:
#!/bin/bash
# Check the calendar-month.tsx implementation for animation details
ast-grep --pattern 'm.tbody' calendar-month.tsx
# Check the calendar transitions implementation
cat packages/components/calendar/src/calendar-transitions.ts
# Check for any motion-related imports in calendar-month
rg -l "import.*motion" packages/components/calendar/src/calendar-month.tsx
Length of output: 641
Script:
#!/bin/bash
# Check the full content of calendar-month.tsx to verify animation implementation
cat packages/components/calendar/src/calendar-month.tsx
# Check if there are any other animation-related files in the calendar component
fd -e ts -e tsx . packages/components/calendar/src
Length of output: 4557
packages/core/system/src/provider.tsx (1)
9-9
: Verify motion configuration compatibility
The import of MotionConfig
and MotionGlobalConfig
from motion/react maintains the same API as framer-motion. The reducedMotion
prop types remain compatible.
✅ Verification successful
Motion configuration import change is compatible
The migration from framer-motion to motion/react maintains API compatibility:
- The
MotionConfig
component is used consistently with the same props interface - The
reducedMotion
prop maintains the same values: "user" | "always" | "never" - All existing usage patterns in the codebase remain unchanged
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check for any remaining MotionConfig imports from framer-motion
rg 'MotionConfig.*framer-motion'
# Check for consistent usage of MotionConfig from motion/react
rg 'MotionConfig.*motion/react'
Length of output: 292
Script:
#!/bin/bash
# Check the usage context of MotionConfig to verify API compatibility
ast-grep --pattern 'MotionConfig'
# Check for any reducedMotion prop usage
rg 'reducedMotion' -A 2
Length of output: 3915
packages/utilities/framer-utils/src/transition-utils.ts (1)
1-1
: Verify type compatibility between framer-motion and motion/react
The import change looks correct. However, we should verify that the imported types (Target
, TargetAndTransition
, Transition
) maintain the same interface in the motion library to ensure backward compatibility.
✅ Verification successful
Import change is part of a broader migration pattern
The change from framer-motion
to motion/react
is consistent with a codebase-wide migration pattern. The search results show that multiple components are already using imports from motion/react
, including the same types (Target
, TargetAndTransition
, Transition
) and related motion types (HTMLMotionProps
, Variants
). This indicates a deliberate migration strategy across the codebase.
- No files are importing these types from
framer-motion
anymore - Multiple components (
tabs
,tooltip
,popover
,modal
,navbar
,calendar
) are already usingmotion/react
- The types are being used consistently in transition-related utilities
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Compare type definitions between framer-motion and motion/react
# Check if both packages are installed and compare their type definitions
# Search for type definitions in node_modules
fd -t f -e d.ts "index.d.ts" node_modules/framer-motion node_modules/motion
Length of output: 255
Script:
#!/bin/bash
# Let's search for type definitions in the codebase
rg -g "*.ts" -g "*.d.ts" "type (Target|TargetAndTransition|Transition)" --type-add 'ts:*.{ts,tsx}' -A 2
# Also search for any references to these types
rg -g "*.ts" -g "*.d.ts" "(Target|TargetAndTransition|Transition)(\s*[:<]|^type)" --type-add 'ts:*.{ts,tsx}' -l
Length of output: 1158
Script:
#!/bin/bash
# Let's check if there are any other files using these types from framer-motion
rg -g "*.ts" -g "*.d.ts" "from ['\"]framer-motion['\"]" --type-add 'ts:*.{ts,tsx}'
# And check for any files using these types from motion/react
rg -g "*.ts" -g "*.d.ts" "from ['\"]motion/react['\"]" --type-add 'ts:*.{ts,tsx}'
Length of output: 1149
packages/components/accordion/src/accordion-item.tsx (1)
1-1
: Verify motion components API compatibility
The import changes look correct. The component uses animation features that are critical for the accordion functionality. We should verify that the motion components (LazyMotion
, AnimatePresence
, m
) maintain the same API in the new library.
Also applies to: 6-6
✅ Verification successful
Let me analyze the search results to verify the motion components API compatibility.
The search results show that the motion components (LazyMotion
, AnimatePresence
, m
) are being used consistently across multiple components in the codebase with the same API patterns:
LazyMotion
is used with thefeatures
prop anddomAnimation
/domMax
AnimatePresence
is used as a wrapper with the same props (mode="wait"
or no mode)m
component is used with the same animation props (animate
,exit
,initial
)
Let me verify the accordion component's specific usage:
Motion components API compatibility verified
The motion components in the accordion component maintain the same API patterns as used across the codebase:
LazyMotion
is used withfeatures={domAnimation}
propAnimatePresence
is used withinitial={false}
m
component is used with standard animation props (animate
,exit
,initial
)- The component uses the same
TRANSITION_VARIANTS
from@nextui-org/framer-utils
The import changes from framer-motion to motion/react are safe as the API usage remains consistent with the rest of the codebase.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Search for any breaking changes in motion components usage
# Look for any existing usages that might break with the new API
# Search for LazyMotion, AnimatePresence, and m component usage patterns
rg -A 3 "LazyMotion|AnimatePresence|m\."
Length of output: 68054
Script:
#!/bin/bash
# Search for motion components usage in accordion files
rg -A 3 "LazyMotion|AnimatePresence|m\." packages/components/accordion/
Length of output: 7256
packages/components/modal/src/modal-content.tsx (1)
2-2
: Verify modal animation behavior
The import changes look correct. Since this component handles critical modal animations, we should verify that the animation behavior remains identical with the new motion library.
Also applies to: 8-8
✅ Verification successful
Based on the search results, I can see that the modal animation behavior in modal-content.tsx
follows a consistent pattern with other components in the codebase. The modal uses standard motion variants and props:
- It uses
TRANSITION_VARIANTS.fade
for the backdrop - Uses
scaleInOut
variants for the modal wrapper - Follows the same animation pattern (
animate="enter"
,exit="exit"
,initial="exit"
) as other components like popover, tooltip, etc.
Since the animation configuration remains identical and only the import path has changed from framer-motion
to motion/react
, the animation behavior should remain the same.
Let me verify the transition variants to be completely sure.
Modal animation behavior verified successfully
The animation configuration is consistent and safe. The modal uses the same transition variants from @nextui-org/framer-utils
package that are shared across components. The scaleInOut
variant for the modal wrapper and TRANSITION_VARIANTS.fade
for the backdrop remain unchanged, only the import path has been updated from framer-motion
to motion/react
.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check for any motion-specific props or animation patterns that might break
# Look for animation-related props and variants
# Search for motion-specific props and animation patterns
rg -A 3 "variants=|animate=|initial=|exit="
# Search for HTMLMotionProps usage
ast-grep --pattern 'HTMLMotionProps<$_>'
Length of output: 11820
Script:
#!/bin/bash
# Check the transition variants definition
rg -g '*.{ts,tsx}' "TRANSITION_VARIANTS|scaleInOut" -A 3
Length of output: 6531
packages/components/date-picker/src/date-range-picker.tsx (1)
10-10
: LGTM: Import change looks correct
The change from framer-motion to motion/react for AnimatePresence is consistent with the PR objective and maintains the same functionality.
apps/docs/components/blog/video-in-view.tsx (1)
4-4
: Verify useInView behavior remains consistent
While the import change is correct, the useInView hook is critical for the video's visibility detection and autoplay functionality.
✅ Verification successful
useInView hook implementation is correctly used and behavior remains consistent
The implementation shows that useInView is used appropriately for visibility detection:
- The hook is used with a video element reference
- The visibility state controls video playback in auto mode
- The implementation follows the standard InView pattern for both framer-motion and motion libraries
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for any useInView hook usage variations or configurations
rg "useInView" --type ts --type tsx -C 2
Length of output: 68
Script:
#!/bin/bash
# Search for useInView usage with ripgrep, including both .ts and .tsx files
rg "useInView" -t ts -t tsx -C 2
# Also check the specific file content to understand the implementation
cat "apps/docs/components/blog/video-in-view.tsx"
Length of output: 4346
packages/components/tabs/src/tab.tsx (1)
12-12
: Verify animation features compatibility
The change from framer-motion to motion/react includes multiple motion-related imports (m, domMax, LazyMotion) used for the tab cursor animation. While the import change is correct, we should ensure the animation features and behavior remain identical.
✅ Verification successful
Animation features are compatible and correctly implemented
The code shows that the animation features from framer-motion have been correctly migrated to motion/react with identical functionality:
- The cursor animation uses the same spring-type transition with identical configuration (bounce: 0.15, duration: 0.5)
- LazyMotion with domMax is properly implemented for the cursor animation
- Layout animations (layoutId, layoutDependency) are used in the same way
- The animation can still be disabled via disableAnimation and disableCursorAnimation props
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for any motion-specific features or configurations
rg "LazyMotion|domMax|layoutId|layoutDependency" --type ts --type tsx -C 2
# Look for any motion-specific transition configurations
rg "transition.*type.*spring" --type ts --type tsx -C 2
Length of output: 190
Script:
#!/bin/bash
# Search for any motion-specific features or configurations with correct file type
rg "LazyMotion|domMax|layoutId|layoutDependency" -t typescript -t tsx -C 2
# Look for any motion-specific transition configurations
rg "transition.*type.*spring" -t typescript -t tsx -C 2
# Check the tab component implementation for animation usage
fd -e tsx -e ts "tab" --exec cat {}
Length of output: 82593
Script:
#!/bin/bash
# Search for the tab component implementation to verify animation usage
cat packages/components/tabs/src/tab.tsx
# Search for any motion-specific animation configurations in the tab component
rg -t ts -t tsx "transition.*type.*spring|layoutId|layoutDependency" packages/components/tabs/src/
Length of output: 4523
packages/components/select/src/select.tsx (1)
12-12
: LGTM! Verify AnimatePresence API compatibility.
The import change from framer-motion to motion/react is correct. The usage pattern remains unchanged.
Let's verify no other motion imports are missed:
✅ Verification successful
Import change verified and usage is consistent
The verification confirms:
- Only one motion-related import exists:
AnimatePresence
from "motion/react" AnimatePresence
is used correctly for conditional rendering withdisableAnimation
flag- No other motion components, animations, or transitions are present in the file
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for any remaining framer-motion imports in select.tsx
rg "framer-motion" packages/components/select/src/select.tsx
# Search for other potential motion components that might need migration
ast-grep --pattern 'import {$_} from "framer-motion"' packages/components/select/src/select.tsx
Length of output: 158
Script:
#!/bin/bash
# Let's check for any motion-related imports in select.tsx
rg "from ['\"].*motion" packages/components/select/src/select.tsx
# Let's also check the actual usage of AnimatePresence in the file
ast-grep --pattern 'AnimatePresence' packages/components/select/src/select.tsx
# Check for any motion-related components or hooks usage
rg -A 2 "motion[\.|\[]|animate|transition" packages/components/select/src/select.tsx
Length of output: 514
apps/docs/components/docs/components/code-demo/code-demo.tsx (2)
Line range hint 1-1
: Consider adding a migration guide and updating documentation.
Since this is a breaking change that replaces framer-motion with motion across the codebase:
- Add a migration guide in the documentation explaining:
- Why the change was made
- Required dependency changes
- Any API differences between framer-motion and motion
- Update all relevant documentation pages that reference framer-motion
- Consider adding a codemod to help users migrate their code
Let's check for documentation files that might need updates:
6-6
: LGTM! Verify useInView hook compatibility.
The import change from framer-motion to motion/react is correct. The hook usage and configuration remain unchanged.
Let's verify no other motion imports are missed:
✅ Verification successful
Import change is consistent with codebase-wide migration
The change from framer-motion
to motion/react
is part of a consistent pattern across the entire codebase. The useInView
hook is being used with the same configuration, and all motion-related imports throughout the project are using the motion/react
package. No remaining framer-motion
imports were found.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for any remaining framer-motion imports in code-demo.tsx
rg "framer-motion" apps/docs/components/docs/components/code-demo/code-demo.tsx
# Search for other potential motion hooks that might need migration
ast-grep --pattern 'import {$_} from "framer-motion"' apps/docs/components/docs/components/code-demo/code-demo.tsx
Length of output: 196
Script:
#!/bin/bash
# Let's check for any motion-related imports in the file
rg "from ['\"].*motion" apps/docs/components/docs/components/code-demo/code-demo.tsx
# Let's also check how useInView is being used in the file
ast-grep --pattern 'useInView($$$)'
Length of output: 813
Script:
#!/bin/bash
# Let's check if there are any other files that have already migrated to motion/react
rg "from ['\"]motion/react" .
# And check for any remaining framer-motion imports
rg "from ['\"]framer-motion" .
Length of output: 4388
packages/components/popover/src/free-solo-popover.tsx (1)
13-13
:
Verify motion/react API compatibility
The change from framer-motion to motion/react might introduce breaking changes. The motion library needs to be version 2.7+ as mentioned in the PR description.
Consider adding a migration guide in the changelog to help users transition from framer-motion to motion.
✅ Verification successful
Let me gather more information about the package.json files to check the version constraints.
Based on the results, I can see that the motion package is widely used across the codebase with version constraints of ">=11.11.12 || >=12.0.0-alpha.1" in dependencies and "11.11.12" in devDependencies. Let me verify one more thing about the imports.
The import change from framer-motion to motion/react is consistent with the codebase
The verification shows that:
- The motion/react package is used consistently across the entire codebase
- All required exports (HTMLMotionProps, LazyMotion, m) are available from motion/react
- The package.json files show proper version constraints (>=11.11.12 || >=12.0.0-alpha.1)
- The same motion features and components are used throughout the codebase
The change is part of a larger migration from framer-motion to motion/react, and all necessary APIs are properly exported and used consistently.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check if motion/react exports all required components
ast-grep --pattern 'import {$$$} from "motion/react"' | grep -E 'HTMLMotionProps|LazyMotion|m'
# Verify version constraints in package.json
find . -name "package.json" -exec grep -l "motion" {} \;
Length of output: 4493
Script:
#!/bin/bash
# Check motion dependency version in package.json files
for f in $(find . -name "package.json"); do
echo "=== $f ==="
cat "$f" | grep -A 1 '"motion":'
done
Length of output: 131070
Script:
#!/bin/bash
# Check all imports from motion/react to verify API usage
ast-grep --pattern 'import {$$$} from "motion/react"'
Length of output: 3557
apps/docs/components/docs/components/code-demo/window-resizer.tsx (1)
2-2
:
Verify motion hooks behavior
The component relies on useMotionValue and useTransform hooks for resizing functionality. Ensure these hooks maintain identical behavior in motion/react.
Consider adding unit tests to verify the resizing behavior remains unchanged with the new library.
✅ Verification successful
Migration to motion/react appears consistent across the codebase
The codebase shows a systematic migration from framer-motion to motion/react, with consistent usage patterns. The WindowResizer component's usage of useMotionValue
and useTransform
hooks aligns with the project-wide migration pattern, and these hooks are being used in their standard way for handling resize animations. The implementation shows no custom workarounds or modifications needed for these hooks.
- All motion-related imports throughout the codebase consistently use "motion/react"
- The WindowResizer component uses these hooks in a straightforward manner for resize calculations
- No custom implementations or adaptations of these hooks are found in the codebase
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for any custom implementations or workarounds for these hooks
rg -A 3 "useMotionValue|useTransform" --type ts --type tsx
Length of output: 88
Script:
#!/bin/bash
# Search for any custom implementations or workarounds for these hooks, including both .ts and .tsx files
rg -t typescript -t tsx -A 3 "useMotionValue|useTransform"
# Also check for any motion-related imports to understand the migration pattern
rg -t typescript -t tsx "from ['\"].*motion.*['\"]"
Length of output: 188
Script:
#!/bin/bash
# Search for motion hooks usage in all files
rg "useMotionValue|useTransform" --type-add 'typescript:*.{ts,tsx}'
# Check motion-related imports
rg "from ['\"].*motion.*['\"]" --type-add 'typescript:*.{ts,tsx}'
# Find the specific file to examine its content
fd "window-resizer.tsx$" -t f -x cat {}
Length of output: 10753
apps/docs/components/sandpack/use-sandpack.ts (1)
73-73
:
Update dependency name and verify version compatibility
The dependency has been renamed from framer-motion to motion with version 11.13.1.
Ensure all components are tested with motion v11.13.1 before releasing.
✅ Verification successful
Let me gather more information to verify if this is just a package rename or if there are actual dependencies on framer-motion that need updating.
Let me check one more thing to verify if there are any direct imports of the motion package or any remaining framer-motion imports in the docs app.
Package rename appears to be safe
The change from framer-motion
to motion
in the docs app's dependencies appears to be safe as:
- No direct imports of either
framer-motion
ormotion
were found in the docs app codebase - The package is only listed as a dependency in
apps/docs/package.json
- The version change (11.11.12 to 11.13.1) is a minor version bump, suggesting backward compatibility
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check for any remaining framer-motion dependencies
find . -name "package.json" -exec grep -l "framer-motion" {} \;
# Verify if all components are compatible with motion v11.13.1
rg -l "framer-motion"
Length of output: 3896
Script:
#!/bin/bash
# Check actual imports in the codebase
rg "from ['\"]framer-motion['\"]" -B 1 -A 1
# Check package.json in the docs app to see current dependencies
cat apps/docs/package.json | grep -A 5 -B 5 "motion"
Length of output: 801
Script:
#!/bin/bash
# Check for motion imports in the docs app
rg "from ['\"]motion['\"]" apps/docs/
rg "from ['\"]@?framer-motion['\"]" apps/docs/
Length of output: 96
packages/components/modal/src/use-modal.ts (1)
2-2
: Verify motion library version compatibility
The import change from framer-motion
to motion/react
looks good. However, ensure that the motion library version is 2.7 or higher as mentioned in the PR description.
✅ Verification successful
Motion library version is compatible
The motion
package is installed with version 11.11.12 in the modal component package, which is higher than the required version 2.7. The import change from framer-motion
to motion/react
is safe to use.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check the installed version of motion library
grep -r "\"motion\":" package.json
Length of output: 34
Script:
#!/bin/bash
# Check package.json files in all directories for motion dependency
fd package.json --exec grep -l "motion" {}
# For each found package.json, show the motion dependency version
fd package.json --exec sh -c 'echo "=== $1 ==="; cat "$1" | jq -r ".dependencies.motion // .devDependencies.motion // empty"' sh {}
Length of output: 5838
packages/components/calendar/src/calendar-base.tsx (1)
10-10
: LGTM! Consider testing animation behavior
The import change from framer-motion
to motion/react
for animation components looks good. Since this component uses complex animations with direction states, it would be good to verify that the animation behavior remains consistent.
✅ Verification successful
Import change is part of a consistent migration pattern
The change from framer-motion
to motion/react
is part of a consistent pattern across the codebase. All animation-related imports are using motion/react
, and there are no remaining framer-motion
imports. The animation components (AnimatePresence
, LazyMotion
, MotionConfig
) are used consistently across various components including tooltips, popovers, modals, and other UI elements.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check for any other framer-motion imports that might have been missed
rg "framer-motion" --type ts --type tsx
Length of output: 67
Script:
#!/bin/bash
# Check for any other framer-motion imports with proper file type patterns
rg "framer-motion" -t ts -t typescript -t jsx -t tsx
# Also check for motion/react imports to understand the migration pattern
rg "motion/react" -t ts -t typescript -t jsx -t tsx
# Look for animation-related imports to get a complete picture
ast-grep --pattern 'import {$$$} from "$_"' | rg -i "motion|animate"
Length of output: 5466
apps/docs/content/docs/api-references/nextui-provider.mdx (2)
161-169
: LGTM! Clear property renaming and description
The renaming from skipFramerMotionAnimations
to skipMotionAnimations
and its updated description accurately reflect the transition to the motion library.
70-74
: LGTM! Improved locale list formatting
The locale list is now properly formatted and aligned, making it more readable.
packages/components/navbar/src/use-navbar.ts (1)
17-17
: LGTM: Import statement updated correctly
The change from framer-motion to motion/react is done correctly while maintaining type compatibility.
packages/components/tooltip/src/use-tooltip.ts (1)
4-4
: LGTM: Import statement updated correctly
The change from framer-motion to motion/react is done correctly while maintaining type compatibility.
apps/docs/components/marketing/a11y-otb.tsx (1)
14-14
: LGTM: Import statement updated correctly
The useInView hook import from motion/react is compatible with the previous framer-motion implementation.
✅ Verification successful
Found remaining framer-motion imports that need to be updated
The verification revealed that there are still several files using framer-motion
. Let's check if these are actual imports or just changelog entries:
Import change from framer-motion to motion/react is correctly implemented
The verification shows:
- No active imports from
framer-motion
were found in the codebase - All
useInView
hook usages are consistent with the new import pattern - Previous
framer-motion
references are only in CHANGELOG files and documentation, not in actual code
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Verify that all framer-motion imports have been replaced with motion/react
rg -l "framer-motion"
# Verify the usage of useInView hook across the codebase
ast-grep --pattern 'useInView($$$)'
Length of output: 4516
Script:
#!/bin/bash
# Check for actual framer-motion imports in the codebase
rg "from ['\"]framer-motion['\"]" -l
# Check for direct framer-motion requires
rg "require\(['\"]framer-motion['\"]" -l
Length of output: 89
apps/docs/content/docs/guide/installation.mdx (1)
136-139
: LGTM: Package installation commands are consistent
The installation commands correctly specify the motion
package in both global and individual installation sections.
Also applies to: 231-234
packages/components/popover/src/use-popover.ts (2)
Line range hint 47-47
: LGTM: Motion props interface remains unchanged
The motionProps
property in the interface correctly uses the updated HTMLMotionProps
type from motion/react.
2-2
: Verify type compatibility with motion/react
The import path has been updated from framer-motion
to motion/react
. Ensure that the HTMLMotionProps
type maintains the same structure and compatibility.
✅ Verification successful
Import path change is consistent across the codebase
The verification shows that all HTMLMotionProps
imports are consistently using the motion/react
path across the entire codebase. There are no remaining imports from framer-motion
, indicating this change is part of a broader, consistent update to the codebase.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for other uses of HTMLMotionProps to ensure consistent updates
rg --type typescript "HTMLMotionProps.*framer-motion"
Length of output: 90
Script:
#!/bin/bash
# Search for HTMLMotionProps usage across the codebase
rg "HTMLMotionProps"
# Search for any framer-motion imports
rg "from ['\"]framer-motion['\"]"
# Check package.json files for dependencies
fd "package.json" --exec cat {} \; | grep -E "motion/react|framer-motion"
Length of output: 3117
apps/docs/content/docs/frameworks/nextjs.mdx (1)
149-152
: Verify motion package version compatibility
The change from framer-motion
to motion
requires version 2.7 or higher as mentioned in the PR objectives.
Also applies to: 395-398
✅ Verification successful
Motion package version is compatible
The codebase is already using motion version 11.11.12 or higher across all packages, which meets the version requirement. The package.json files show both direct dependencies of "motion": "11.11.12"
and peer dependencies of "motion": ">=11.11.12 || >=12.0.0-alpha.1"
, confirming compatibility with the change from framer-motion
to motion
.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check package.json for motion version
rg -A 5 '"motion":\s*"[^"]*"' package.json
Length of output: 44
Script:
#!/bin/bash
# Search for motion package in package.json files across the repository
fd package.json --exec rg -A 5 '"motion":\s*"[^"]*"' {}
# Search for motion package in lock files
fd -e lock --exec rg -A 5 '"motion":\s*"[^"]*"' {}
# Search for any motion package imports in the codebase
rg -g '!*.lock' -g '!package.json' "from ['\"]motion['\"]|from ['\"]framer-motion['\"]"
Length of output: 6567
apps/docs/components/navbar.tsx (1)
28-28
: Verify animation functionality with motion/react
The change from framer-motion
to motion/react
affects the animation components. Ensure that all animation features work as expected, particularly:
- The version dropdown animation using
AnimatePresence
- The motion div animations with
animate
,exit
, andinitial
props
✅ Verification successful
Let me generate another script to check the actual usage of motion components in the navbar.tsx file to verify the animation functionality.
Animation functionality is correctly implemented with motion/react
The verification shows that the animations in navbar.tsx are properly implemented using motion/react:
- The version dropdown uses
AnimatePresence
andmotion.div
with correct animation props (opacity transitions) - The import statement and usage patterns match the official motion/react API
- The codebase shows consistent usage of motion/react across multiple components, indicating a standardized approach
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Find other animation-related imports and usages
rg -A 2 'import.*motion'
ast-grep --pattern 'motion.div {
$$$
}'
Length of output: 18645
Script:
#!/bin/bash
# Check the actual usage of motion components in navbar.tsx
cat apps/docs/components/navbar.tsx
Length of output: 12203
apps/docs/config/search-meta.json (2)
Line range hint 1-11099
: LGTM! The search metadata structure is well-organized.
The search metadata configuration follows a consistent and well-structured format with proper hierarchy levels, unique identifiers, and clear content organization. The data structure will work effectively for documentation search functionality.
10777-10784
:
Remove merge conflict markers
There are tilde (~) characters on lines 10777-10784 that appear to be merge conflict markers. These should be removed to ensure proper JSON formatting.
"content": "Why does NextUI use Motion?",
"objectID": "d76533f7-0ca8-40cd-b77a-80f708d8d744",
"type": "lvl3",
"url": "/docs/guide/introduction#why-does-nextui-use-motion",
"hierarchy": {
"lvl1": "Introduction",
"lvl2": "Can I use NextUI with other front-end frameworks or libraries, such as Vue or Angular?",
"lvl3": "Why does NextUI use Motion?"
}
Likely invalid or redundant comment.
@@ -34,13 +34,13 @@ | |||
"postpack": "clean-package restore" | |||
}, | |||
"peerDependencies": { | |||
"framer-motion": ">=11.5.6 || >=12.0.0-alpha.1", | |||
"motion": ">=11.11.12 || >=12.0.0-alpha.1", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This change requires a major version bump
The replacement of framer-motion with motion constitutes a breaking change as it requires users to:
- Remove the framer-motion dependency
- Install the new motion dependency
- Update their import statements from 'framer-motion' to 'motion/react'
Consider:
- Bumping the major version number
- Adding a migration guide to the documentation
- Including clear upgrade instructions in the changelog
@@ -36,7 +36,7 @@ | |||
"peerDependencies": { | |||
"react": ">=18 || >=19.0.0-rc.0", | |||
"react-dom": ">=18 || >=19.0.0-rc.0", | |||
"framer-motion": ">=11.5.6 || >=12.0.0-alpha.1", | |||
"motion": ">=11.11.12 || >=12.0.0-alpha.1", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Consider documenting this as a breaking change
The switch from framer-motion to motion is a breaking change as users need to install a different package. This should be clearly documented in the changelog and migration guide.
"clean-package": "2.2.0", | ||
"motion": "11.11.12", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
💡 Codebase verification
Motion version needs an update for consistency
The motion package version (11.11.12) is outdated compared to the latest stable version (11.13.1). While the peerDependency range (>=11.11.12) is correct, the devDependency should be updated for consistency with other packages in the monorepo:
apps/docs
is already using motion@11.13.1- Multiple components are importing from "motion/react" and would benefit from consistent versioning
- The latest stable version (11.13.1) includes bug fixes and improvements over 11.11.12
🔗 Analysis chain
Verify motion version compatibility
The devDependency is pinned to 11.11.12 while peerDependency allows >=11.11.12. Let's verify if this is the latest stable version and check for any known issues.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check package.json files for version consistency
rg --type json '"motion":\s*"[^"]*"' -g 'package.json'
# Check for motion imports to ensure compatibility
rg --type typescript "from\s+['\"]motion/" -g '!node_modules'
Length of output: 3092
Script:
#!/bin/bash
# Check for motion imports with .ts and .tsx extensions
rg "from\s+['\"]motion/" -g '*.{ts,tsx}'
# Check the latest version of motion package
npm view motion versions --json | jq -r '.[]' | tail -n 5
Length of output: 4392
@@ -36,7 +36,7 @@ | |||
"peerDependencies": { | |||
"@nextui-org/system": ">=2.4.0", | |||
"@nextui-org/theme": ">=2.4.0", | |||
"framer-motion": ">=11.5.6 || >=12.0.0-alpha.1", | |||
"motion": ">=11.11.12 || >=12.0.0-alpha.1", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Document this as a breaking change
The replacement of framer-motion with motion is a breaking change as it requires users to:
- Remove framer-motion dependency
- Install motion@>=11.11.12
This should be clearly documented in the changelog and release notes.
Also applies to: 71-71
@@ -36,7 +36,7 @@ | |||
"peerDependencies": { | |||
"@nextui-org/system": ">=2.4.0", | |||
"@nextui-org/theme": ">=2.4.0", | |||
"framer-motion": ">=11.5.6 || >=12.0.0-alpha.1", | |||
"motion": ">=11.11.12 || >=12.0.0-alpha.1", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
💡 Codebase verification
🛠️ Refactor suggestion
Breaking change documentation and version bump required
The migration from framer-motion to motion package requires:
- Version bump to 3.0.0 following semver for breaking changes
- Documentation of the migration in either package.json description or README
- Consider adding migration notes as other components (@nextui-org/docs) have already switched to motion v11.13.1
🔗 Analysis chain
Breaking change needs documentation in package.json
While the dependency updates are correct and consistent with other components, consider:
- Adding a note in the package.json description or README about the migration from framer-motion to motion
- Updating the version number according to semver since this is a breaking change
Consider updating the version field:
- "version": "2.3.3",
+ "version": "3.0.0",
Let's check if other components have documented this breaking change:
Also applies to: 76-76
Let me gather more information about version changes and migration documentation.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check for any migration notes in package descriptions
fd package.json | xargs jq -r '. | select(.description != null) | select(.description | contains("motion")) | "\(.name): \(.description)"'
Length of output: 211
Script:
#!/bin/bash
# Check current versions and dependencies of components
fd package.json | xargs jq -r '. | select(.name != null and .version != null) | select(.dependencies.motion != null or .dependencies."framer-motion" != null) | "\(.name):\n version: \(.version)\n motion: \(.dependencies.motion // "none")\n framer-motion: \(.dependencies."framer-motion" // "none")"'
# Check for any migration notes in README files
fd README.md | xargs grep -l -i "motion" || true
Length of output: 427
npm: 'npm i @nextui-org/react motion', | ||
yarn: 'yarn add @nextui-org/react motion', | ||
pnpm: 'pnpm add @nextui-org/react motion', | ||
bun: "bun add @nextui-org/react motion" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Update requirements section to match motion library
The requirements section still mentions "Framer Motion 11.9" while the installation commands have been updated to use the motion
package. This inconsistency could confuse users.
Please update the requirements section to specify the correct package name and version requirement for the motion library.
@@ -93,7 +93,7 @@ | |||
"peerDependencies": { | |||
"react": ">=18 || >=19.0.0-rc.0", | |||
"react-dom": ">=18 || >=19.0.0-rc.0", | |||
"framer-motion": ">=11.5.6 || >=12.0.0-alpha.1" | |||
"motion": ">=11.11.12 || >=12.0.0-alpha.1" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
💡 Codebase verification
Breaking change confirmed - Documentation update needed
Based on the verification results:
- The
motion
package is published on npm with versions up to12.0.0-alpha.2
- The version constraint
>=11.11.12 || >=12.0.0-alpha.1
is valid - The change is not documented in the recent changelog entries
- The switch from
framer-motion
tomotion
is a breaking change as it requires users to update their dependencies
This change should be documented in the changelog under a breaking changes section to ensure users are aware they need to update their dependencies from framer-motion
to motion
.
🔗 Analysis chain
Consider documenting this as a breaking change
The switch from framer-motion
to motion
as a peer dependency is a breaking change that requires users to update their dependencies. This should be clearly documented in the changelog and release notes.
Additionally, verify if the version constraint >=11.11.12
aligns with the minimum version that includes all required features from framer-motion.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check if the motion package is published and its versions
curl -s https://registry.npmjs.org/motion | jq '.versions | keys[]' | sort -V | tail -n 5
Length of output: 155
Script:
#!/bin/bash
# Check for any usage of framer-motion specific imports or features in the codebase
rg -l "framer-motion" --type ts --type tsx
# Check the git history for any previous version constraints of framer-motion
git log -p -- packages/core/react/package.json | grep -A 2 -B 2 "framer-motion"
Length of output: 70
Script:
#!/bin/bash
# Check for any usage of framer-motion specific imports or features in the codebase
rg -l "framer-motion"
# Find all TypeScript/JavaScript files that might use motion-related imports
fd -e ts -e tsx -e js -e jsx -x cat {} | rg "from ['\"]@?framer-motion['\"]" -l
Length of output: 3919
Script:
#!/bin/bash
# Check the content of the latest changelog entries for any breaking change documentation
cat packages/core/react/CHANGELOG.md | head -n 50
# Check the actual imports in the codebase to see motion usage
rg "from ['\"]motion['\"]" -l
Length of output: 1538
@@ -58,7 +58,7 @@ | |||
"color2k": "2.0.3", | |||
"contentlayer2": "0.5.3", | |||
"date-fns": "4.1.0", | |||
"framer-motion": "11.11.13", | |||
"motion": "11.13.1", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Breaking Change: Package replacement requires user action.
The replacement of framer-motion with motion@11.13.1 is a breaking change that requires users to update their dependencies. As mentioned in the PR description, users need to install motion v2.7 or higher.
However, there seems to be a version mismatch:
- PR description mentions motion v2.7+
- Package.json specifies motion v11.13.1
Please clarify the correct version requirement and ensure it's consistently documented.
@@ -12,7 +12,7 @@ Requirements: | |||
- [Tailwind CSS 3.4](https://tailwindcss.com/) or later | |||
- [Framer Motion 11.9](https://www.framer.com/motion/) or later | |||
|
|||
----- | |||
----- |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
💡 Codebase verification
Package name inconsistency needs to be corrected
The documentation shows an inconsistency between the requirement and installation instructions:
- It mentions "Framer Motion 11.9" as a requirement
- But instructs users to install the
motion
package instead offramer-motion
This needs to be corrected as motion
is a different package and its latest version (2.0.0) is not compatible with Framer Motion 11.9.
🔗 Analysis chain
Verify version requirement consistency
The document specifies Framer Motion 11.9 as a requirement, but the installation commands use the motion
package. This might confuse users about which package to install.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check if motion package is compatible with framer-motion 11.9
curl -s https://registry.npmjs.org/motion | jq '.versions | keys[]' | grep -E "2\.[0-9]+\.[0-9]+"
Length of output: 124
Script:
#!/bin/bash
# Search for framer-motion version references in the upgrade guide
rg -i "framer.?motion.*11\.9" apps/docs/content/docs/guide/upgrade-to-v2.mdx
# Check if there are any motion package installation commands
rg -i "npm (install|add|i) motion" apps/docs/content/docs/guide/upgrade-to-v2.mdx
rg -i "yarn add motion" apps/docs/content/docs/guide/upgrade-to-v2.mdx
rg -i "pnpm (add|install) motion" apps/docs/content/docs/guide/upgrade-to-v2.mdx
# Also check for framer-motion installation commands
rg -i "npm (install|add|i) framer-motion" apps/docs/content/docs/guide/upgrade-to-v2.mdx
rg -i "yarn add framer-motion" apps/docs/content/docs/guide/upgrade-to-v2.mdx
rg -i "pnpm (add|install) framer-motion" apps/docs/content/docs/guide/upgrade-to-v2.mdx
Length of output: 755
I don't really know why pnpm can't load
|
📝 Description
framer-motion changed to motion https://motion.dev/blog/framer-motion-is-now-independent-introducing-motion
⛳️ Current behavior (updates)
🚀 New behavior
This changes the framer-motion occurences to motion.
💣 Is this a breaking change (Yes/No):
I'm not sure how to proceed with BC here. Tell users to install motion since v2.7+?
📝 Additional Information
Summary by CodeRabbit
New Features
framer-motion
tomotion/react
across various components, enhancing animation capabilities.Documentation
framer-motion
tomotion
.Chores
framer-motion
withmotion
, ensuring consistency in dependency management.