Conversation
|
The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message. To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook. |
|
Size Change: 0 B Total Size: 2.37 MB ℹ️ View Unchanged
|
| const packageJsonCache = new Map(); | ||
|
|
||
| /** | ||
| * @typedef {Object} PackageJson |
There was a problem hiding this comment.
Typescript would have been handy haha :)
|
Flaky tests detected in 2922a38. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/18871476046
|
|
|
||
| // Cache for package.json data | ||
| const packageJsonCache = new Map(); | ||
| // @ts-expect-error: No types available |
| try { | ||
| const resolved = import.meta.resolve( | ||
| `${ fullPackageName }/package.json` | ||
| ); | ||
| const packageJson = JSON.parse( | ||
| readFileSync( fileURLToPath( resolved ), 'utf8' ) | ||
| ); | ||
| packageJsonCache.set( packageJson.name, packageJson ); | ||
| return packageJson; | ||
| } catch ( error ) { | ||
| packageJsonCache.set( fullPackageName, null ); | ||
| return null; | ||
| } |
There was a problem hiding this comment.
Should these two functions compose each other? They're doing a lot of the same work.
| try { | |
| const resolved = import.meta.resolve( | |
| `${ fullPackageName }/package.json` | |
| ); | |
| const packageJson = JSON.parse( | |
| readFileSync( fileURLToPath( resolved ), 'utf8' ) | |
| ); | |
| packageJsonCache.set( packageJson.name, packageJson ); | |
| return packageJson; | |
| } catch ( error ) { | |
| packageJsonCache.set( fullPackageName, null ); | |
| return null; | |
| } | |
| const resolved = import.meta.resolve( | |
| `${ fullPackageName }/package.json` | |
| ); | |
| return getPackageInfoFromFile( fileURLToPath( resolved ) ); |
| * @param {string} str String in kebab-case format. | ||
| * @return {string} String in camelCase format. | ||
| */ | ||
| export function kebabToCamelCase( str ) { |
There was a problem hiding this comment.
We have change-case as a dependency in the root package.json, should we use it? I think in some ways it's "overkill" if we have a specialized use-case here, but these are the types of functions which are quick to write but full of edge case bugs.
| `${ fullPackageName }/package.json` | ||
| ); | ||
| const packageJson = JSON.parse( | ||
| readFileSync( fileURLToPath( resolved ), 'utf8' ) |
There was a problem hiding this comment.
Would be nice to shift to async file operations.
There was a problem hiding this comment.
This comment is going to require a lot of changes, so I'm going to keep it for later. I'll address the rest of the comments in #72743
| * Get PHP replacements from root package.json. | ||
| * | ||
| * @param {string} rootDir Root directory path. | ||
| * @return {Promise<Object>} Replacements object with {{PREFIX}}, {{VERSION}}, {{VERSION_CONSTANT}}. |
There was a problem hiding this comment.
I've typically seen Object be discouraged in favor of object or Record<...> types
|
|
||
| // Write output file | ||
| await mkdir( path.dirname( outputPath ), { recursive: true } ); | ||
| await writeFile( outputPath, content, 'utf8' ); |
There was a problem hiding this comment.
| await writeFile( outputPath, content, 'utf8' ); | |
| await writeFile( outputPath, content ); |
| `^${ packageName.replace( | ||
| /[.*+?^${}()|[\]\\]/g, | ||
| '\\$&' | ||
| ) }$` |
There was a problem hiding this comment.
Understanding this already existed, but: What is this doing? An inline code comment could be helpful
| // e.g., '@wordpress/blocks/sub/path' → packageName='@wordpress/blocks', subpath='sub/path' | ||
| const parts = args.path.split( '/' ); | ||
| const packageName = | ||
| parts.length >= 2 |
There was a problem hiding this comment.
This will always be true? The filter explicitly matches strings with a slash, so the split result will always have 2 parts.
There was a problem hiding this comment.
Could probably simplify this to something like...
let packageName = args.path;
let subpath = null;
if ( parts.length > 2 ) {
packageName = parts.slice( 0, 2 ).join( '/' );
subpath = parts.slice( 2 ).join( '/' );
}Or with splicing to avoid a second slice: (needs extra handling for shortName)
let packageName = args.path;
let subpath = null;
if ( parts.length > 2 ) {
packageName = parts.splice( 0, 2 ).join( '/' );
subpath = parts.join( '/' );
}| path.join( templatesDir, 'module-registration.php.template' ), | ||
| 'utf8' | ||
| ); | ||
| const replacements = await getPhpReplacements( ROOT_DIR ); |
There was a problem hiding this comment.
This could be a shared constant at the top of the file?
| "packages/build-vendors.mjs", | ||
| "packages/build.mjs", | ||
| "packages/check-build-type-declaration-files.js", | ||
| "packages/dependency-graph.js", |
Related #72032
What?
Refactors the package build tool to be fully portable and removes hardcoded path assumptions.
Why?
A few things that were solved
@wordpress/prefix assumptions instead of reading actual package namesHow?
getPackageInfoFromFile()getPackageInfo()Testing Instructions
Built tool is run in CI, so e2e tests should pass basically/