Packages are lacking proper dependencies #1630
Comments
|
Hi @swissspidy I haven't had a chance to look into it yet, but it looks like this is due to a GH workflow error: It would be lovely if it was not possible to partially publish new package versions. |
|
Both packages with large archive sizes,
I'm going to re-attempt the package publishing job. It will probably bump the version number again, but if this was a momentary error, it will be worth it to fix the latest packages. |
|
Ah, right. The failed publish was likely |
|
Rerunning the workflow didn't fail but also didn't appear to publish anything. |
|
Next things to try:
|
## Motivation for the change, related issues This PR removes support for WP 6.2 which is unsupported following the WP 6.6 release. The actual motivation for this change is to try to work around the npm package release error encountered here: https://github.com/WordPress/wordpress-playground/actions/runs/9960370683/job/27519444281 With this change the `@wp-playground/wordpress-builds` unpacked size goes from 529M to 485M (based on `du` utility output for a local build). Lerna reported that the previous, successful release of the package had a size of 363.5 MB. Related to #1630 ## Testing Instructions (or ideally a Blueprint) - CI - Use `npm run dev` to confirm that WP 6.2 is no longer offered as an option in the UI and that Playground continues to load without error.
|
I attempted publishing NPM again without any changes to The latest version is now 0.9.22, but the latest for @adamziel @bgrgicak I could use your help with this. It seems like this needs a more surgical touch, possibly even a manual update for |
brandonpayton
added
[Type] Bug
|
I restarted it and it worked this time https://github.com/WordPress/wordpress-playground/actions/runs/10014830477/job/27730750651. |
|
Nice, that sounds promising! 🚀 Now my only remaining ask is to add a |
|
@bgrgicak I tried that as well, but restarting the failed job doesn't seem to do anything for The latest version should be 0.9.23 to go along with the rest of the packages like: |
|
Ideally it would be able to distinguish between imports from Aside of that, we could really use a CI job to run a smoke test on the built packages – do they import / run cleanly after building both as CJS and ESM? Here’s something related I’ve built a long time ago – I don’t think is used a lot now and then it only treats the built packages without actually linking them in another directory and running |
## Motivation for the change, related issues We are running into trouble publishing the wordpress-builds package, and it isn't really needed to begin with. It is big, takes time to download, and is leading to problems for our users. Let's stop publishing the library and eliminate unintended dependencies on it. Related to #1630 ## Implementation details This PR marks the `@wp-playground/wordpress-builds` package as private, and that appears to do the trick. ## Testing Instructions (or ideally a Blueprint) - CI - Manually run the workflow to publish packages to NPM and retry repro instructions from #1630 to confirm the fix ```bash npx --yes @wp-playground/cli start ```
## Motivation for the change, related issues A couple of our NPM packages don't declare their dependencies resulting in problems like those reported in #1630. ## Implementation details This PR updates two NX projects to update package.json with dependencies as part of the build process. ## Testing Instructions (or ideally a Blueprint) - CI
## Motivation for the change, related issues
The ajv library was listed as a dev dependency, but it is used by the
actual blueprints library.
Without this, consumers of the `@wp-playground/blueprints` library
encounter an error due to missing ajv lib.
```
npx --yes @wp-playground/cli start
node:internal/errors:496
ErrorCaptureStackTrace(err);
^
Error [ERR_MODULE_NOT_FOUND]: Cannot find package 'ajv' imported from /Users/brandon/src/temp/node_modules/@wp-playground/blueprints/index.js
at new NodeError (node:internal/errors:405:5)
at packageResolve (node:internal/modules/esm/resolve:916:9)
at moduleResolve (node:internal/modules/esm/resolve:973:20)
at defaultResolve (node:internal/modules/esm/resolve:1193:11)
at ModuleLoader.defaultResolve (node:internal/modules/esm/loader:404:12)
at ModuleLoader.resolve (node:internal/modules/esm/loader:373:25)
at ModuleLoader.getModuleJob (node:internal/modules/esm/loader:250:38)
at ModuleWrap.<anonymous> (node:internal/modules/esm/module_job:76:39)
at link (node:internal/modules/esm/module_job:75:36) {
code: 'ERR_MODULE_NOT_FOUND'
}
```
Related to #1630
## Implementation details
This PR switches `ajv` from a dev dependency to a normal dependency.
## Testing Instructions (or ideally a Blueprint)
CI
|
@swissspidy, I reviewed the other packages for other missing dependencies and fixed what I found. The dependency issues should now be fixed, at least for your use case. The following runs successfully on my machine: % npx --yes @wp-playground/cli server
Starting a PHP server...
Setting up WordPress latest
Running the Blueprint...
Running the Blueprint – 100%
Finished running the blueprint
WordPress is running on http://127.0.0.1:9400Does it work for you now? |
|
Yep, looks like it's working now! |
|
Thank you so much @brandonpayton! |
I wanted to install
@wp-playground/clivia npm but I'm getting an error because it requires version 0.9.20 of@wp-playground/wordpress-buildswhich for some reason isn't published to npm:Pinning to 0.9.19 works, but then I'm getting an error because
@wp-playground/blueprintsis looking for@php-wasm/scopeswhich is not installed because it is not in thedependenciessection of the package.If they are properly added, then maybe I am able to install these packages via npm
The text was updated successfully, but these errors were encountered: