Skip to content

Include JS build files in the Composer package in v0.2.0 release #100

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.

Sign up for GitHub

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

Jump to bottom
Merged
gziolo merged 1 commit into from
Oct 3, 2025
Merged

Include JS build files in the Composer package in v0.2.0 release #100

gziolo merged 1 commit into from
Oct 3, 2025

Conversation

@gziolo
Copy link
Member

@gziolo gziolo commented Oct 3, 2025 •
edited
Loading

This PR improves the configuration for Composer package by ensuring only files from packages/client/build and packages/client/build-types get included.

Now, the question is whether we really need build-types if build folder contains code ready for use on production exposed through wp.abilities global.

@emdashcodes or @budzanowski, what would be the purpose of including build-types here? Should we include package.json, too?

On the higher level, It feels to me like we should keep the build files in the top-level folder mirroring Gutenberg like:

build/client/

In Gutenberg, we store different types of content inside local build folder:

  • build is Common JS version of the package (import/export replaced with require/module.exports)
  • build-module is more like ES Modules version of the code

These are modified sources that are compiled with Babel with small changes that ensure these files can run in all browsers.

Testing instructions

Run git archive --format=zip HEAD -o archive.zip to check the contents of the Composer package:

Screenshot 2025-10-03 at 10 10 25

@gziolo gziolo requested a review from emdashcodes October 3, 2025 08:29
@codecov
Copy link

codecov bot commented Oct 3, 2025 •
edited
Loading

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 85.69%. Comparing base (45cfa27) to head (54d9765).

Additional details and impacted files 
@@              Coverage Diff               @@
##             release/0.2     #100   +/-   ##
==============================================
  Coverage          85.69%   85.69%           
  Complexity           103      103           
==============================================
  Files                 16       16           
  Lines                776      776           
  Branches              86       85    -1     
==============================================
  Hits                 665      665           
  Misses               111      111
Flag Coverage Δ
javascript 92.66% <ø> (ø)
unit 82.97% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
  • 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

@gziolo gziolo added the [Tool] Issues related to development tooling, such as linting, testing, or CI label Oct 3, 2025
@gziolo gziolo self-assigned this Oct 3, 2025
@gziolo
Copy link
Member Author

gziolo commented Oct 3, 2025 •
edited
Loading

For comparison, I include 54d9765 that has packages/client/build-type ignored:

Screenshot 2025-10-03 at 11 22 47

@gziolo gziolo marked this pull request as ready for review October 3, 2025 09:23
@gziolo gziolo added this to the v0.2.0 milestone Oct 3, 2025
@github-actions
Copy link

github-actions bot commented Oct 3, 2025 •
edited
Loading

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: gziolo <[email protected]>
Co-authored-by: emdashcodes <[email protected]>
Co-authored-by: budzanowski <[email protected]>

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

@gziolo gziolo force-pushed the fix/release-0.2.0-build branch from 959e352 to 54d9765 Compare October 3, 2025 09:24
@budzanowski
Copy link
Contributor

budzanowski commented Oct 3, 2025

@emdashcodes or @budzanowski, what would be the purpose of including build-types here? Should we include package.json, too?

build-types
Yes. TypeScript developers who import the package need these files for type checking and autocomplete.
Should you include package.json?

package.json files
Yes. It tells bundlers and TypeScript where to find the code and type definitions. Without it, imports like import { getAbilities } from '@wordpress/abilities' won't work.

Should you mirror Gutenberg's structure with build/client/?
Yes, if you want consistency. It makes the package structure familiar to WordPress developers and follows established conventions. Is it necessary - no

emdashcodes
emdashcodes approved these changes Oct 3, 2025
View reviewed changes
Copy link
Contributor

@emdashcodes emdashcodes left a comment

Choose a reason for hiding this comment

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

The types would be useful for anyone pulling this in to a TS project. It is not strictly required though.

They would need to configure their tsconfig at the moment to include something like

"@wordpress/abilities": [
    "./vendor/wordpress/abilities-api/packages/client/build-types"
]

This would only be considered temporary until we publish the npm package which will include the types.

I don't have a strong preference for where things are stored. I need to look a little closer at how all the Gutenberg packages are stored.

@gziolo
Copy link
Member Author

gziolo commented Oct 3, 2025

The types would be useful for anyone pulling this in to a TS project. It is not strictly required though.

I was contemplating how that could be done. Happy to remove the commit that excludes build-types as a temporary measure.

@gziolo gziolo force-pushed the fix/release-0.2.0-build branch from 54d9765 to bcb1c7e Compare October 3, 2025 12:24
@gziolo gziolo merged commit fa5b4b0 into release/0.2 Oct 3, 2025
39 checks passed
@gziolo gziolo deleted the fix/release-0.2.0-build branch October 3, 2025 12:29
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@emdashcodes emdashcodes emdashcodes approved these changes

+1 more reviewer

@budzanowski budzanowski budzanowski approved these changes

Reviewers whose approvals may not affect merge requirements

Assignees

@gziolo gziolo

Labels

[Tool] Issues related to development tooling, such as linting, testing, or CI

Projects

None yet

Milestone

v0.2.0

Development

Successfully merging this pull request may close these issues.

4 participants

@gziolo @budzanowski @emdashcodes