Size Change: +3.78 kB (0%)

Total Size: 1.51 MB

_{compressed-size-action}

@youknowriad explored replacing Babel plugin with the proposal for JSON modules in #34176. That could be used as a reference as we didn't continue with the PR because it was a stage 3 proposal, and WordPress uses only accepted proposals. Anyway, it's good to cross-check changes applied to ensure all necessary file paths get updated.

It's a separate discussion whether we are fine using more custom features supported by bundlers like JSON imports.

Edit: I'm a little bit confused about the current status of import proposals as they include different syntax:

• https://github.com/tc39/proposal-import-attributes
• https://github.com/tc39/proposal-json-modules

I'm a little bit confused about the current status of import proposals as they include different syntax:

The with { type: 'json' } syntax seems to be some latest update. Chrome and Firefox support natively (and experimentally) only the assert { type: 'json' } one.

My PR doesn't use the import assertions at all, it just makes use of webpack's support for JSON module. The assertions are there for security purposes -- to make it harder to trick the browser into parsing source of type X as source of type Y.

There is still need to stop using the named exports, like import { name } from './block.json'. The native implementations doesn't support them at all, and webpack issues warnings when you do that. Riad's PR doesn't migrate them.

I have two immediately actionable takeaways from this work:

1. there is bug in block serialization, accidentally discovered when I worked on this PR. Separately addressed in Block serialization: correctly compare default attribute values #53521.
2. I have doubts whether it's a good idea to do block.json imports just to get a block's name, like import { name } from '../paragraph/block.json'. Core block names are stable, succint and well known. Simply hardcoding a 'core/paragraph' identifier seems much better to me. Such references to block names are already ubiquitous. WDYT?

IMO we can't defer json imports to the application layer (webpack) without relying on the import json proposal because `import something from "./file.json" is not standard and shouldn't be included in the "output" of npm packages.

Warning: Type of PR label mismatch

To merge this PR, it requires exactly 1 label indicating the type of PR. Other labels are optional and not being checked here.

• Type-related labels to choose from: [Type] Automated Testing, [Type] Breaking Change, [Type] Bug, [Type] Build Tooling, [Type] Code Quality, [Type] Copy, [Type] Developer Documentation, [Type] Enhancement, [Type] Experimental, [Type] Feature, [Type] New API, [Type] Task, [Type] Performance, [Type] Project Management, [Type] Regression, [Type] Security, [Type] WP Core Ticket, Backport from WordPress Core.
• Labels found: [Type] Build Tooling, [Type] Experimental.

Read more about Type labels in Gutenberg. Don't worry if you don't have the required permissions to add labels; the PR reviewer should be able to help with the task.

That's true, although I've been surprised how good the support for import assertions already is. Except Firefox, evergreen browsers all support JSON imports. And Firefox has an experimental javascript.options.experimental.import_assertions flag for them.

https://caniuse.com/mdn-javascript_statements_import_import_assertions_type_json

I can be onboard with import assertions but the fact that the initial proposal changed already make me a bit nervous.

the fact that the initial proposal changed already make me a bit nervous.

I looked at some of the TC39 meeting notes and slides and this is a summary of what happened:

• in January 2023 the proposal was demoted from Stage 3 to Stage 2 because of some very technical security issue about compatibility with CSP.
• the issue was solved and since March 2023 the proposal is back in Stage 3.
• the keyword has been changed from assert to with because there is interest in having generic "import attributes", for example, in TypeScript. Your environment can define a foo attribute and do import './module.js' with { foo: 'whatever' }. And foo is not necessarily an "assertion", that's a too narrow word, it's a generic "attribute".
• there are existing mainstream implementations like Chrome or Node 16+ which support assert, so the assert keyword will continue to be valid, probably indefinitely.

import something from "./file.json" is not standard

That's true, but for practical purposes, it's "almost there". Node 16+ supports it, it will just print a warning:

ExperimentalWarning: Importing JSON modules is an experimental feature. This feature could change at any time

And the HTML standard already says that a compliant HTML implementation must support JSON modules.

But we can wait until it really becomes an undisputed standard, at this moment I'd say it's a matter of months, not years.

IMO, we can still make the migration in the source code if we find a way to "bundle" these in the output of the packages. And "months" sounds good to me.