Skip to content

Migrate keycodes package to TypeScript #70466

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

Open
wants to merge 8 commits into
base: trunk
Choose a base branch
from

Conversation

im3dabasia
Copy link
Contributor

What?

Part of: #67691
Migrating the keycodes package to Typescript.

Why?

Type safety.

Testing Instructions

Typecheck and unit tests.

@im3dabasia im3dabasia marked this pull request as ready for review June 19, 2025 12:22
Copy link

github-actions bot commented Jun 19, 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: im3dabasia <[email protected]>
Co-authored-by: manzoorwanijk <[email protected]>
Co-authored-by: sirreal <[email protected]>
Co-authored-by: tyxla <[email protected]>

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

@im3dabasia im3dabasia changed the title [WIP]: Migrate keycodes package to TypeScript Migrate keycodes package to TypeScript Jun 19, 2025
@t-hamano t-hamano added [Type] Code Quality Issues or PRs that relate to code quality [Package] Keycodes /packages/keycodes labels Jun 20, 2025
@t-hamano t-hamano mentioned this pull request Jun 24, 2025
36 tasks
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 to me. Thank you for working on this.

I would like @jsnajdr @tyxla @gziolo to have another look.

@tyxla
Copy link
Member

tyxla commented Jul 14, 2025

Unfortunately, I'm a bit away from the typing work these days. I'd appreciate it if one of the other pinged folks could have a look. Or maybe @sirreal would have some spare cycles?

Copy link
Member

@sirreal sirreal 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 the work on this! Overall it looks good, I left a few suggestions to improve some things.

@@ -0,0 +1,56 @@
/**
Copy link
Member

Choose a reason for hiding this comment

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

The file rename unfortunately does not pick up the diff.

It appears that most of the changes are adding as Window type assertions to the test values passed in to isAppleOs.

diff at 05d3d3e
diff --git a/packages/keycodes/src/test/platform.js b/packages/keycodes/src/test/platform.ts
index 63cd2628f98..8a91afe824f 100644
--- a/packages/keycodes/src/test/platform.js
+++ b/packages/keycodes/src/test/platform.ts
@@ -5,50 +5,52 @@ import { isAppleOS } from '../platform';
 
 describe( 'isAppleOS helper', () => {
 	it( 'should identify anything with "Mac" in it as Apple OS', () => {
-		expect( isAppleOS( { navigator: { platform: 'Mac' } } ) ).toEqual(
-			true
-		);
-		expect( isAppleOS( { navigator: { platform: 'MacIntel' } } ) ).toEqual(
-			true
-		);
+		expect(
+			isAppleOS( { navigator: { platform: 'Mac' } } as Window )
+		).toEqual( true );
+		expect(
+			isAppleOS( { navigator: { platform: 'MacIntel' } } as Window )
+		).toEqual( true );
 	} );
 
 	it( 'should identify "iPad" as Apple OS', () => {
-		expect( isAppleOS( { navigator: { platform: 'iPad' } } ) ).toEqual(
-			true
-		);
+		expect(
+			isAppleOS( { navigator: { platform: 'iPad' } } as Window )
+		).toEqual( true );
 	} );
 
 	it( 'should identify "iPhone" as Apple OS', () => {
-		expect( isAppleOS( { navigator: { platform: 'iPhone' } } ) ).toEqual(
-			true
-		);
+		expect(
+			isAppleOS( { navigator: { platform: 'iPhone' } } as Window )
+		).toEqual( true );
 	} );
 
 	it( 'should not identify Windows as MacOS', () => {
-		expect( isAppleOS( { navigator: { platform: 'Windows' } } ) ).toEqual(
-			false
-		);
-		expect( isAppleOS( { navigator: { platform: 'Win' } } ) ).toEqual(
-			false
-		);
+		expect(
+			isAppleOS( {
+				navigator: { platform: 'Windows' },
+			} as Window )
+		).toEqual( false );
+		expect(
+			isAppleOS( { navigator: { platform: 'Win' } } as Window )
+		).toEqual( false );
 	} );
 
 	it( 'should not identify *NIX as MacOS', () => {
-		expect( isAppleOS( { navigator: { platform: 'Linux' } } ) ).toEqual(
-			false
-		);
-		expect( isAppleOS( { navigator: { platform: 'Unix' } } ) ).toEqual(
-			false
-		);
+		expect(
+			isAppleOS( { navigator: { platform: 'Linux' } } as Window )
+		).toEqual( false );
+		expect(
+			isAppleOS( { navigator: { platform: 'Unix' } } as Window )
+		).toEqual( false );
 	} );
 
 	it( 'should not identify other cases as MacOS', () => {
-		expect( isAppleOS( { navigator: { platform: 'MAC' } } ) ).toEqual(
-			false
-		);
-		expect( isAppleOS( { navigator: { platform: 'mac' } } ) ).toEqual(
-			false
-		);
+		expect(
+			isAppleOS( { navigator: { platform: 'MAC' } } as Window )
+		).toEqual( false );
+		expect(
+			isAppleOS( { navigator: { platform: 'mac' } } as Window )
+		).toEqual( false );
 	} );
 } );

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Would it be wise to leave the tests untouched? I see plenty of packages which are in TS have their tests in JS. WDYT?

Copy link
Member

Choose a reason for hiding this comment

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

To clarify, I commented and shared the diff to document the changes for posterity since it shows up as a delete/add in GitHub UI.

In this situation where every test requires an assertion and nothing else is changed, I would probably have left the file unchanged. I'll leave this case up to you.

* @param mapFn - Mapping function to apply to each value.
* @return Object with the same keys and transformed values.
*/
function mapValues< T extends Record< string, any >, R >(
Copy link
Member

Choose a reason for hiding this comment

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

This looks like it changed in this PR, before T extended { [s: string]: any; } | ArrayLike<any> in the Template, here it's Record< string, any >.

This function is internal and only appears to be passed the modifiers object, so that seems fine.

Copy link
Member

@sirreal sirreal left a comment

Choose a reason for hiding this comment

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

Thanks! I think there's one comment remaining to be addressed (#70466 (comment)) but otherwise this looks good.

Co-authored-by: Jon Surrell <[email protected]>
@manzoorwanijk manzoorwanijk enabled auto-merge (squash) July 31, 2025 06:18
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Package] Keycodes /packages/keycodes [Type] Code Quality Issues or PRs that relate to code quality
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants