The recent relocation of a native stylesheet from a src sub-directory to a top-level src directory uncovered incompatibility with existing, broad glob patterns. The packages/block-freeform/src/style.native.scss was previously in a src sub-directory.

Native stylesheets require additional configuration to "auto-import" various Sass variables. That configuration is unsupported by the bin/packages/build.js script. Additionally, building native stylesheets is unnecessary for web builds.

https://github.com/WordPress/gutenberg/actions/runs/16144205849/job/45558646305?pr=70644

Error: Undefined variable.
   ╷
18 │     color: $light-secondary;
   │            ^^^^^^^^^^^^^^^^
   ╵
  packages/block-freeform/src/style.native.scss 18:9  root stylesheet
    at Object.wrapException (/home/runner/work/gutenberg/gutenberg/node_modules/sass/sass.dart.js:1246:17)
    at /home/runner/work/gutenberg/gutenberg/node_modules/sass/sass.dart.js:71374:23
    at _wrapJsFunctionForAsync_closure.$protected (/home/runner/work/gutenberg/gutenberg/node_modules/sass/sass.dart.js:3741:15)
    at _wrapJsFunctionForAsync_closure.call$2 (/home/runner/work/gutenberg/gutenberg/node_modules/sass/sass.dart.js:28239:12)
    at Object._asyncStartSync (/home/runner/work/gutenberg/gutenberg/node_modules/sass/sass.dart.js:3705:20)
    at _EvaluateVisitor2.visitVariableExpression$body$_EvaluateVisitor0 (/home/runner/work/gutenberg/gutenberg/node_modules/sass/sass.dart.js:71380:16)
    at _EvaluateVisitor2.visitVariableExpression$1 (/home/runner/work/gutenberg/gutenberg/node_modules/sass/sass.dart.js:71354:19)
    at VariableExpression0.accept$1$1 (/home/runner/work/gutenberg/gutenberg/node_modules/sass/sass.dart.js:98828:22)
    at VariableExpression0.accept$1 (/home/runner/work/gutenberg/gutenberg/node_modules/sass/sass.dart.js:98831:19)
    at /home/runner/work/gutenberg/gutenberg/node_modules/sass/sass.dart.js:74362:42 {
  type: 'Error',
  '$error': '$error',
  formatted: 'Error: Undefined variable.\n' +
    '   ╷\n' +
    '18 │     color: $light-secondary;\n' +
    '   │            ^^^^^^^^^^^^^^^^\n' +
    '   ╵\n' +
    '  packages/block-freeform/src/style.native.scss 18:9  root stylesheet',
  line: 18,
  column: 9,
  file: '/home/runner/work/gutenberg/gutenberg/packages/block-freeform/src/style.native.scss',
  status: 1

If we do not register the block, the mobile editor is unable to render the proper fallback UI bundled with the block itself.

I wonder if we can move the fallback UI around if necessary. @ellatrix do you have any concerns with how we're still importing, but effectively hiding the classic block from inserter?

I don't get what you're doing here? Why are you adding a dependency to the freeform package? Why not register it in the proper package like edit-post? (I don't know what mobile is using.)

I don't get what you're doing here? Why are you adding a dependency to the freeform package?

I reinstated the implementation introduced in #22609. I added a dependency to the freeform package because that is the new location of the "classic" block type.

Why not register it in the proper package like edit-post? (I don't know what mobile is using.)

I have no argument against using the edit-post package. I was merely unaware that it was "proper." I will explore relocating the freeform block type registration in edit-post and follow up on this PR.

Thanks, sorry I wasn't clear on the reasoning 🙂

This is still a blocker for merging it imo, it would be good if we can move registering the block to edit-post (if that's the package that mobile uses)

I relocated in the core/freeform registration to occur in the edit-post package in 8596792.

Without this file, the fallback UI has no styling and throws build errors.

This is just the missing block stylesheet right? Can'we just reuse that, rather than duplicating it?

Yes, I believe the same could be said for duplicating the JavaScript file to packages/block-freeform/src/missing.native.js as well. I presume the duplication there was done to avoid creating a dependency on @wordpress/block-library.

If a dependency is not a concern, both the JavaScript and stylesheet could be imported from @wordpress/block-library.

@ellatrix was there a particular reason for duplicating the Missing JavaScript file?

I don't see why we should depend on block library tbh 🤔

1. I don't get why classic needs to depend on the missing block. Why can't it have its own fallback UI? Even better, at render the HTML and allow code editing.
2. If you really want to reuse missing block code and styles, I don't think a bit of duplication is a bad thing. If these are things a block might generally use, maybe it should move to the placeholder component or something.

I don't get why classic needs to depend on the missing block. Why can't it have its own fallback UI? Even better, at render the HTML and allow code editing.

My focus in this PR was addressing a regression in the current experience. I'd prefer not modifying the functionality within the context of a pull request focused on relocating files (#70603). Is it alright if we take this approach of solely refactoring and avoiding functionality changes?

If you really want to reuse missing block code and styles, I don't think a bit of duplication is a bad thing. If these are things a block might generally use, maybe it should move to the placeholder component or something.

I have no objection to the duplication, personally.

To my understanding, the manner in which the mobile editor is using Missing today is essentially a placeholder for unsupported block types. Are you referring to something specific when you say "move to the placeholder component?"

@ellatrix: you have a point here on the duplication and dependency of the package. I say let's add a TODO comment for addressing the duplication in the future, and proceed as-is.

Is it alright if we take this approach of solely refactoring and avoiding functionality changes?

100%

Are you referring to something specific when you say "move to the placeholder component?"

Yes, I was referring to the placeholder component in the block-editor package. Generally if components are reused by blocks, I'd prefer these utils or components to move there (maybe even as a public API if it's useful to blocks).

Of course I'd also prefer to keep the functionality the same in this PR, so I'm fine with the duplication

Yes, I was referring to the placeholder component in the block-editor package. Generally if components are reused by blocks, I'd prefer these utils or components to move there (maybe even as a public API if it's useful to blocks).

To ensure I am not misunderstanding: are you referring to the Placeholder component located within @wordpress/components that is used within @wordpress/block-editor?

I wonder if we can move the fallback UI around if necessary. @ellatrix do you have any concerns with how we're still importing, but effectively hiding the classic block from inserter?

This is just the missing block stylesheet right? Can'we just reuse that, rather than duplicating it?