Assets: Build JS & CSS files

[obenland]

Building on #1673, this PR adds the JS and CSS files in /assets to the entry points of npm run build. It minimizes the files and adds RTL support for stylesheets. This PR also adds RTL support to the post preview.

Proposed changes:

• Adds webpack extention to account for /assets entrypoints.
• Updates script and style references to use the build versions.
• Adds RTL support to Post Preview.

After

Changelog entry

• [x] Automatically create a changelog entry from the details below.

Changelog Entry Details

Significance

• [ ] Patch
• [x] Minor
• [ ] Major

Type

• [x] Added - for new features
• [ ] Changed - for changes in existing functionality
• [ ] Deprecated - for soon-to-be removed features
• [ ] Removed - for now removed features
• [ ] Fixed - for any bug fixes
• [ ] Security - in case of vulnerabilities

Message

Post Preview now supports RTL languages. Embed and wp-admin styles are optimized for RTL languages.

[pfefferle]

This PR seem to change the way how we work with "static" js. Can you maybe add a switch, to use the asset file in dev mode ( maybe using https://developer.wordpress.org/reference/functions/wp_get_environment_type/) and/or write a doc about how to best use it in the daily development process.

[obenland]

Good call on updating the docs!

It does change the way we work with these files, bringing it inline with how blocks are developed. It shouldn't be necessary to switch modes as long as these files get edited while running npm run dev.

With that in mind, I do wonder if it would make sense to move these js and css files into /src, to keep all the files that get built in one place?

[pfefferle]

let's move them to source to be consistent. maybe we should use a proper folder structure and mimic the block file pattern a bit?

[obenland]

Yeah, happy to move them to src. I'm not sure there's much benefit to creating a fake block structure around them.

[pfefferle]

Not a fake block structure, but more descriptive folder structures and simpler file names. There is no need to prefix them for example.

[obenland]

Cool, yeah I think I did that.

[pfefferle]

I am not sure about the folder structure... This is a bit inconsistent... Shouldn't we reuse the folder structure of the blocks even if it is not a block?

Like:

admin
    ├── header-image.js
    ├── wp-admin.js
    └── style.scss

and

embed
    └── style.scss

[obenland]

Oh, I see! I think we could do something like that. Let me experiment with it a bit.

The limiting factor will be the discoverability of entry points. Currently we can say "any file in /js and /css is an entry point" and don't have to manually add new ones to Webpack. If we were to break it out in arbitrary folders, that would no longer work.

However, we could try moving all blocks into a /blocks folder and say "any file not in /blocks is an entry point" and see if that works.

[pfefferle]

I would do the /blocks folder "hack"! We have so many points in the code where we decided to be explicit over implicit, so I see no issue to properly configure every new asset we add!?!

[obenland]

The good news: I managed to make it work to combine scripts and styles in folders and still be recognized as entry points. The bad news: I forgot to update .prettierignore with the new paths for blocks before building and pushing, so they're now all prettified. I think that should be fine though.

[pfefferle]

why do the blocks have to be in the blocks subfolder? why not have everything on one level?

[obenland]

why do the blocks have to be in the blocks subfolder? why not have everything on one level?

Practically because blocks are built differently than the other JS/CSS file. It also helps with organization, alongside the wp-admin and embed folders