Skip to content
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

Consider using @wordpress/scripts rather than Parcel 2. #98

Closed
tcmulder opened this issue Apr 4, 2024 · 3 comments
Closed

Consider using @wordpress/scripts rather than Parcel 2. #98

tcmulder opened this issue Apr 4, 2024 · 3 comments

Comments

@tcmulder
Copy link
Owner

tcmulder commented Apr 4, 2024

No description provided.

@tcmulder
Copy link
Owner Author

tcmulder commented Apr 4, 2024

Currently I've got an experimental branch going, v7.0.0_wpscripts. There's also older work on a v7.0.0_wpscripts_sass branch in which I converted all .css files to .scss.

@tcmulder
Copy link
Owner Author

tcmulder commented Apr 8, 2024

This has some great potential since:

  1. It's maintained by the community.
  2. It has 1st class support for @wordpress/* packages.
  3. It outputs even .php files to dist, which is logical: all js/css/php then gets served from dist (assets could even be deleted in prod).
  4. The vast majority of examples I could copy/paste online should work out of the box.

But, it does currently come with some caveats:

  1. It's "Fast Refresh" doesn't seem to work in LocalWP, but rather wp-env+Docker.
  2. BrowserSync works, but since all files apparently change every save, it won't inject changes but do a full refresh every save.
  3. There's a lot more output than Parcel 2, which is annoying: I like how Parcel just shows Browser Sync output and then refreshes itself inline.
  4. I got it working on the v7.0.0_wpscripts branch, but it's just an odd patch: it has difficulty handling similar files like view.css and view.js, attempting to override one with the other.
  5. I got PostCSS working, but it prefers SCSS, so some features may misbehave.
  6. I haven't even started testing autoprefixer, browser version support adherence, linting and IDE hinting, and some other features.
  7. I tried getting --experimental-modules working for viewScriptModule and "interactivity": true, but it won't even compile. (Since this is experimental, they may fix it, but it may only work for block development rather than block+theme development).
  8. SVG's won't inline; to get block SVG's to work then, I need to search for @wordpress/scripts's SVG loader and add an ignore to it for inline SVGs, then implement my own. It works, but it feels fragile, like if they change the SVG regex a bit it will fail (it still builds but doesn't show the icon).

Here are some good resources:

  1. Developer Hours episode.
  2. Example theme using @wordpress/scripts for theme (rather than block) development.

@tcmulder
Copy link
Owner Author

tcmulder commented Apr 10, 2024

Acceptance criteria:

  • Nested blocks work (or reconfigured that feature to put blocks alongside their parents, in which case I should refactor aquamin/grd).
  • Confirm all the wp-cli scripts still work.
  • Hint/lint work.
  • Autoprefixer works, and uses package.json's browser list.
  • Blocks have back-end icons (and maybe inline SVG works as before).
  • (optionally) Works automatically with .scss files.
  • (optionally) Works with interactivity API. ⚠️ only works if @wordpress/interactivity remains unchanged in view.js and the dependency in grd-view.asset.php, but webpack currently rewrites those to wp.interactivity and wp-interactivity, respectively.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Development

No branches or pull requests

1 participant