-
-
Notifications
You must be signed in to change notification settings - Fork 110
[core] Re-use latest code infra scripts from core repo #1662
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
base: master
Are you sure you want to change the base?
Conversation
f4f8757
to
b1f0f5e
Compare
✅ Deploy Preview for base-ui ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
✅ Deploy Preview for base-ui ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
d73ca0c
to
eb0c574
Compare
fd5c639
to
68de990
Compare
console.error(error); | ||
process.exit(1); | ||
}); | ||
import '@mui/monorepo/scripts/testBuiltTypes.mjs'; |
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.
Can keep it for now, but looking at the script, I assume this is unnecessary if your declarations are built from typescript files.
Actually, it's looking for mui-*
segments in the paths, which would never occur in the base ui repo.
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.
Actually, it's looking for mui-* segments in the paths
True. I wonder if it was even working as intended.
scripts/useReactVersion.mjs
Outdated
@@ -37,7 +37,9 @@ async function main(version) { | |||
return; | |||
} | |||
|
|||
const packageJsonPath = path.resolve(getWorkspaceRoot(), 'package.json'); | |||
const currentDirectory = url.fileURLToPath(new URL('.', import.meta.url)); | |||
const workspaceRoot = path.resolve(currentDirectory, '..'); |
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.
Can't this script just default to process.cwd()
and add the script to root package.jsons scripts. Then it will always run with cwd of the root, regardless of whether it's executed from a subfolder.
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.
My personal preference is not to include everything in package.json scripts to avoid cluttering them, especially if the script is only used by the CI.
}); | ||
const invalidFiles = declarationFiles.filter((file) => { | ||
const content = fs.readFileSync(file, 'utf8'); | ||
const regex = /import\(["']packages\//gm; |
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.
🤔 I feel like this is trying to do the exact same thing as testBuiltTypes. And probably as irrelevant when declarations are generated from ts instead of handwritten.
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 script was created to prevent issues such as mui/material-ui#33321 (caused by referencing a type that's not exported).
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.
🤔 I'm suspecting the root cause of that issue is the use of baseUrl
. We should try if we can still reproduce this bug with that option removed.
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.
Personally, I would remove the getWorkspaceRoot
logic in favor for process.cwd()
. Then never run the script directly, but always through a package.json script. That makes this script more portable within and across projects.
Looks great otherwise, I have a feeling some of those type validation scripts are a bit unnecessary.
48e9447
to
ad27d41
Compare
By portable, you mean copy pastable to new repos in any directory, right ? |
No, I mean the location in the file system of the script makes no difference on whether it behaves correctly. So we can simply move it to a published package and make it available in the path with package.json bin and it'll still work. I don't think we should encourage copy/pasting these tools. |
The way this particular script works right now, it'll need to be copy pasted unless we change that. |
ad27d41
to
44c7614
Compare
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.
Great job. I can't reproduce any problem that would break the types validation functions. @michaldudak for a final approval.
44c7614
to
23819b6
Compare
23819b6
to
65fdda6
Compare
65fdda6
to
8a21680
Compare
@@ -37,7 +36,8 @@ async function main(version) { | |||
return; | |||
} | |||
|
|||
const packageJsonPath = path.resolve(getWorkspaceRoot(), 'package.json'); | |||
const workspaceRoot = process.cwd(); |
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.
Now we're in a state where we must run the script from the root directory and don't have it added to npm scripts to enforce the correct working directory. My preference would be to leave the previous version, but if you and @Janpot like reading process.cwd
and calling the script from npm, let's have it your way.
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.
Wouldn't this script always have to run from the root directory anyways given it needs to modify root package.json
And the current invocation of script will remain as is even if it is added to package.json scripts.
Not sure I fully understand.
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.
but if you and @Janpot like reading process.cwd and calling the script from npm, let's have it your way.
FYI: I don't really have some bizarre fetish to see process.cwd()
😄. My preference would be that we centralize this script instead of copying it over multiple repositories. In that scenario, the getWorkspaceRoot()
as implemented in this repo would never work as it would exist in a different location relative to the workspace root (such as in the node_modules folder). Any CLI tool we use operates on the current working dir, or its parents. That's why I advocate for not writing our scripts in a way that its location in the file system matters. That way we make it easy for them to be distributed across the company.
Personally, for this script, I think it's a bit overkill to look for a root, but as always, code infra can only work when the project teams buy in to the idea. So if there is a strong desire for the functionality we can certainly add it back, but I believe the correct implementation should be to start from process.cwd()
and progressively check parent folders for a pnpm-workspace.yaml
file.
Removed all the local code wherever possible and used scripts from the core repo.