Skip to content
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

[core] Move @mui/internal-test-utils to dev dependency #13318

Merged
merged 3 commits into from
May 31, 2024

Conversation

LukasTy
Copy link
Member

@LukasTy LukasTy commented May 30, 2024

Fixes #13317.

  • Move the @mui/internal-test-utils dependency from dependencies to devDependencies on the @mui/x-data-grid package.
  • Change version to a stable released package 1.0.0.

WDYT @mui/code-infra, wouldn't it be more correct if the internal package stable versions were released with the latest flag instead of next? 🤔
Screenshot 2024-05-30 at 23 37 00

@LukasTy LukasTy added bug 🐛 Something doesn't work core Infrastructure work going on behind the scenes labels May 30, 2024
@LukasTy LukasTy self-assigned this May 30, 2024
@mui-bot
Copy link

mui-bot commented May 30, 2024

Deploy preview: https://deploy-preview-13318--material-ui-x.netlify.app/

Generated by 🚫 dangerJS against 0c3f0d1

@LukasTy LukasTy requested review from a team May 30, 2024 21:27
Copy link
Member

@cherniavskii cherniavskii left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for fixing this!

@DysektAI
Copy link

Possible to get this merged?
I actually updated about an hour ago and got quite the warning output which was odd. I'm sure this is worthy of a small patch.

Output:

@LukasTy LukasTy merged commit 35f56dc into mui:master May 31, 2024
19 checks passed
@LukasTy LukasTy deleted the move-internal-test-utils-to-dev branch May 31, 2024 06:01
@LukasTy LukasTy mentioned this pull request May 31, 2024
@Janpot
Copy link
Member

Janpot commented May 31, 2024

I think the plan is to have internal packages always on canary versions in dependent repositories. I'm under the assumption the intention is:

latest: 1.0.0 - published while public packages are published. We don't use this verison in X/Toolpad/base
canary: 1.0.0-dev.20240529-082515-213b5e33ab - published with every change on master. We use this version in X/Toolpad/base. But we specify the exact evrsion number so that renovatebot can automate the upgrade

So, I think the 1.0.0-dev.20240529-082515-213b5e33ab version was as intended. The npm tags seem wrong to me

cc @michaldudak

@LukasTy
Copy link
Member Author

LukasTy commented May 31, 2024

latest: 1.0.0 - published while public packages are published. We don't use this verison in X/Toolpad/base
canary: 1.0.0-dev.20240529-082515-213b5e33ab - published with every change on master. We use this version in X/Toolpad/base. But we specify the exact evrsion number so that renovatebot can automate the upgrade

Ok, gotcha, if that's the intent, we can adjust the approach. 👌
And I think that the tags are correct in such a case because renovate would only suggest bumping a package to a newer latest release, if we'd release all the master pushes as next, then renovate wouldn't prompt for an upgrade.
Am I missing something?

@Janpot
Copy link
Member

Janpot commented May 31, 2024

I suppose we can configure renovatebot to follow a specific tag, but since this is an internal package we can probably leave it as is

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug 🐛 Something doesn't work core Infrastructure work going on behind the scenes
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Move @mui/internal-test-utils to devdepedencies.
5 participants