Skip to content

Conversation

@yashjawale
Copy link
Contributor

What?

Part of #67691

This PR migrates project-management-automation package to use TypeScript

Why?

Migrating to TypeScript provides improved type-hinting in the editor & helps identify bugs early on

How?

The PR ports the existing component code to use TypeScript syntax & creates types accordingly as needed

Testing Instructions

The existing unit tests for the component should suffice

@im3dabasia im3dabasia added [Type] Code Quality Issues or PRs that relate to code quality [Package] Project management automation /packages/project-management-automation labels Aug 14, 2025
@yashjawale yashjawale marked this pull request as ready for review August 14, 2025 13:51
@github-actions
Copy link

github-actions bot commented Aug 14, 2025

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 props-bot label.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: yashjawale <[email protected]>
Co-authored-by: manzoorwanijk <[email protected]>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

Copy link
Member

@manzoorwanijk manzoorwanijk left a comment

Choose a reason for hiding this comment

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

This action is used here

- uses: ./packages/project-management-automation

And we need to ensure that the package is built before we can use that.

@manzoorwanijk
Copy link
Member

One option might be to update the Node version of the repo to greater than v23 here

20

and then use Node to naively run TS code.

@yashjawale
Copy link
Contributor Author

I'm worried about changing the node version as an LTS version hasn't been released yet after 22 & don't know how existing code might react to changes...

I'll try having the package built before running workflow...

@yashjawale yashjawale requested a review from desrosj as a code owner August 18, 2025 06:53
@yashjawale
Copy link
Contributor Author

I've updated the PR to build the package in workflow but can't seem to tackle error in Lint action. Perhaps it refers to files currently in trunk branch...?

Following the method used by report-flaky-tests package & end2end-test.yml...

@manzoorwanijk
Copy link
Member

I've updated the PR to build the package in workflow but can't seem to tackle error in Lint action. Perhaps it refers to files currently in trunk branch...?

Following the method used by report-flaky-tests package & end2end-test.yml...

You can fix that by adding this to paths in .github/actionlint.yml

    .github/workflows/pull-request-automation.yml:
        ignore:
            # This file gets created in the previous step.
            - 'file "build/index.js" does not exist.+'

@yashjawale
Copy link
Contributor Author

Thanks 🙌
Updated the PR with the same
I'll sync branch with trunk in a while so the other Unit Tests pass

Copy link
Member

@manzoorwanijk manzoorwanijk left a comment

Choose a reason for hiding this comment

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

This looks good overall but I am not sure how we can test it to ensure it works fine.

@manzoorwanijk
Copy link
Member

How can we verify that it works fine when a new pull request is opened?

@yashjawale
Copy link
Contributor Author

yashjawale commented Aug 19, 2025

Perhaps I can temporarily modifying the workflow file to use the branch in my fork & then create a test PR in the fork itself to see if everything works?

Or using act? But that won't guarantee identical results on real repo

@yashjawale
Copy link
Contributor Author

Or maybe move this to a temp branch on this repository & then create PR against that test branch. By modifying the workflow temporarily to only run when PR is opened against that branch

    pull_request_target:
        types: [opened]
        branches: [temp/refactor-ts-migration-project-management-automation]

I see nock is also an installed package, maybe we can use that in some way to mock GitHub API & write tests...? I don't have much idea how that works but can learn about it if needed

@manzoorwanijk
Copy link
Member

Perhaps I can temporarily modifying the workflow file to use the branch in my fork & then create a test PR in the fork itself to see if everything works?

That sounds like a good approach.

@manzoorwanijk
Copy link
Member

Or maybe move this to a temp branch on this repository & then create PR against that test branch. By modifying the workflow temporarily to only run when PR is opened against that branch

Sounds better

@yashjawale
Copy link
Contributor Author

Which approach would be preferred to start among the two?
For the latter I don't think I have access to create new branches here

Copy link
Member

@manzoorwanijk manzoorwanijk left a comment

Choose a reason for hiding this comment

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

I tested it via #71341 and it seems to work fine.

Let us make some changes to improve it.

Comment on lines 32 to 34
- name: Npm build
# TODO: We don't have to build the entire project, just the action itself.
run: npm run build:packages
Copy link
Member

@manzoorwanijk manzoorwanijk Aug 25, 2025

Choose a reason for hiding this comment

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

Let us complete the TODO in this PR

  • Rename the lib directory in packages/project-management-automation to src to ensure this works here
    const pkgSrcPath = path.resolve( PACKAGES_DIR, pkgName, 'src' );
  • Update include in packages/project-management-automation/tsconfig.json to "src"
  • Then, instead of building all the packages, we can run node bin/packages/build.js packages/project-management-automation/src/**/*.ts
  • We can also update the name here to say "Build project automation package" instead of "Npm build"

@yashjawale
Copy link
Contributor Author

Updated ✅

Similar TODO is also present in end2end-test.yml, should we update that one too?

- name: Npm build
# TODO: We don't have to build the entire project, just the action itself.
run: npm run build:packages

@manzoorwanijk
Copy link
Member

Yeah, that would be nice

@yashjawale
Copy link
Contributor Author

Updated

@manzoorwanijk
Copy link
Member

Thank you.

There might be a slight delay in reviewing as I'm at WCUS 2025. I'll try to test it as soon as I can.

@yashjawale
Copy link
Contributor Author

Thanks for the update! Have a great time at WCUS 🔥

@manzoorwanijk
Copy link
Member

I tested it after multiple attempts, finally getting it right but it seems to fail for some reason. You can see the run here.

Can you debug it on your fork to see what is wrong?

@yashjawale
Copy link
Contributor Author

My findings...

  1. Checkout ref in workflow file is set to trunk, so the the source files were still in lib while the workflow was looking at src directory
image (Verify file structure step that just does a `ls -R` on package directory)

Ref: https://github.com/yashjawale/gutenberg/actions/runs/17288801117/job/49071157142?pr=1

  1. The shell was not expanding the **/*.ts wildcard into a list of files before passing it to build script, modified PR to include the fix which expands the selector first & then adds each file as argument
              run: |
                  shopt -s globstar
                  files=(packages/project-management-automation/src/**/*.ts)
                  node bin/packages/build.js "${files[@]}"

After that the workflow seems to be working

Ref: https://github.com/yashjawale/gutenberg/actions/runs/17290157291/job/49075407406?pr=1

- name: Build report flaky tests package
run: node bin/packages/build.js packages/report-flaky-tests/src/**/*.ts
run: |
shopt -s globstar
Copy link
Member

Choose a reason for hiding this comment

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

I'm not sure if we need to glob here because the build script already does it when we use the wildcard. May be we should wrap that argument in quotes in the workflow yaml? I'm not sure if that is the fix though.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I'll try that & see if it works...

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Wrapping in quotes didn't work...

From examining the build script, ig it doesn't use glob in cases where arguments are provided to the script....

It appears to be using glob in case without command line arguments

if ( files.length ) {
stream = new Readable( { encoding: 'utf8' } );
files.forEach( ( file ) => {
stream.push( file );
} );
stream.push( null );
stream = stream
.pipe( createStyleEntryTransform() )
.pipe( createBlockJsonEntryTransform() );
} else {
const bar = new ProgressBar( 'Build Progress: [:bar] :percent', {
width: 30,
incomplete: ' ',
total: 1,
} );
bar.tick( 0 );
stream = glob.stream(
[
`${ PACKAGES_DIR }/*/src/**/*.{js,ts,tsx}`,

Copy link
Member

Choose a reason for hiding this comment

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

So what is the difference between running in a local terminal and in the workflow? Why does it work locally but not in CI? May be we need to tweak some config to make it behave as glob?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Here's what I could find after a bit of digging around...

Globbing works in bash version 4+, the workflow uses ubuntu-latest runner image which rn uses 24.04 which includes bash 5.2.21(1)-release so that should work

Available runner images
Details of 24.04 image

Most probably globbing doesn't work in non interactive sessions, similar to GitHub actions

Commands run internally by run

If I paste the command in a .sh file & execute that file then the command fails

#!/bin/sh

node bin/packages/build.js packages/project-management-automation/src/**/*.ts
image

But running the same in interactive shell works as intended

Copy link

Copilot AI left a comment

Choose a reason for hiding this comment

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

Pull Request Overview

This PR migrates the project-management-automation package from JavaScript to TypeScript to improve type safety and developer experience. The migration maintains existing functionality while adding proper type annotations and following TypeScript best practices.

  • Converts all source files from JavaScript to TypeScript with proper type annotations
  • Updates build configuration to use TypeScript compilation
  • Replaces CommonJS module syntax with ES modules

Reviewed Changes

Copilot reviewed 16 out of 24 changed files in this pull request and generated 3 comments.

Show a summary per file
File Description
tsconfig.json Updated TypeScript configuration for new source structure and compilation settings
src/test/get-associated-pull-request.js Updated type imports to use Octokit webhook types
src/tasks/first-time-contributor-label/index.ts Converted to TypeScript with proper type annotations and ES module exports
src/tasks/first-time-contributor-account-link/index.ts Migrated to TypeScript with type safety improvements and non-null assertions
src/tasks/assign-fixed-issues/index.ts Converted to TypeScript with proper typing for GitHub API interactions
src/tasks/add-milestone/index.ts Migrated to TypeScript with improved error handling and milestone type definitions
src/index.ts Main entry point converted to TypeScript with proper interface definitions
src/has-wordpress-profile.ts Converted utility function to TypeScript with proper parameter typing
src/get-associated-pull-request.ts Rewritten in TypeScript with improved return type handling
src/debug.ts Simple utility converted to TypeScript with proper typing
package.json Updated main entry point to reference new build directory
lib/get-associated-pull-request.js Removed old JavaScript implementation
action.yml Updated to reference new build output location
.github/workflows/pull-request-automation.yml Added TypeScript build step for the automation package
.github/workflows/end2end-test.yml Updated build process for report-flaky-tests package
.github/actionlint.yml Added ignore rule for generated build files

Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

[Package] Project management automation /packages/project-management-automation [Type] Code Quality Issues or PRs that relate to code quality

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants