"Version" property in block.json is required for SCSS support

[Jorgu5]

Describe the bug

Here I came up with a very strange bug, which caused me today a lot of trouble and couple hours. The problem is that, when "version" property is not defined in block.json, the style and editorStyle properties, when defined like that

{
  "style": "file:./style.css",
  "editorStyle": "file:./editor.css"
}

Are not finding properly the CSS files when bundled from SASS and ending up with an error, despite the fact that style.css and editor.css has been created properly, however based on the source in the error, it's looking in the wrong place (not in dist).

ERROR in ENOENT: no such file or directory, open '.../includes/blocks/accordion/style.css

When you add a version property to the block.json everything works properly.

The problem is that version property is optional as Wordpress documentation states, neither I have found in your documentation strictly that version property is required (it exist in examples though)

Steps to Reproduce

1. Create a simple WP Block with block.json
2. Create styles.scss and add the property style with style.css to the block.json
3. Add / Remove version property.

Screenshots, screen recording, code snippet

{
  "$schema": "https://schemas.wp.org/trunk/block.json",
  "apiVersion": 3,
  "version": "0.1.0" // remove 
  "name": "block/accordion",
  "title": "Accordion",
  "category": "design",
  "icon": "list-view",
  "description": "Create an accordion with multiple expandable sections.",
  "supports": {
    "html": false
  },
  "attributes": {
    "accordionItems": {
      "type": "array",
      "default": [
        {
          "title": "",
          "description": "",
          "image": {
            "id": 0,
            "url": "",
            "alt": ""
          }
        }
      ]
    }
  },
  "example": {
    "attributes": {
      "accordionItems": [
        {
          "id": "example-1",
          "title": "Accordion Item 1",
          "description": "This is the content of accordion item 1."
        },
        {
          "id": "example-2",
          "title": "Accordion Item 2",
          "description": "This is the content of accordion item 2."
        }
      ]
    }
  },
  "editorScript": "file:./index.js",
  "style": "file:./style.css",
  "editorStyle": "file:./editor.css"
}

Environment information

N/A

WordPress information

N/A

Code of Conduct

• I agree to follow this project's Code of Conduct

[nicholasio]

Thanks for you bug report. What's your 10up-toolkit version and are you using useBlockAssets flags?

[Jorgu5]

I'm using 6.2.1 and yes, using useBlockAssets flag together with "useBlockModules and useScriptModules. I haven't tested how it behaves without using these flags

[cr0ybot]

I was able to fix this by specifying the source file in block.json ("style": "file:./style.scss"), but I also had to create a workaround in my local webpack config to transform Sass file extensions to .css in CopyWebpackPlugin. It seems that the automatic version generation code is looking for the style assets defined in the input block.json file, but if you're using a Sass file and have .css in block.json that file doesn't exist. See

10up-toolkit/packages/toolkit/utils/blocks.js

Lines 48 to 57 in 4c4ba03

	if (!hasVersion && isFilePath) {
	styleArray.forEach((rawStylePath) => {
	if (!rawStylePath.startsWith('file:')) {
	return;
	}
	const stylePath = rawStylePath.replace('file:', '');
	const absoluteStylePath = path.join(absoluteDirectory, stylePath);
	styleFileContentHash += getFileContentHash(absoluteStylePath);
	});
	}

@nicholasio I can open a PR if that's cool. My fix would be to treat Sass files the same way that TypeScript files are treated, by expecting the source file to be defined in block.json and adding a transform for the file extension within CopyWebpackPlugin.

[nicholasio]

I was able to fix this by specifying the source file in block.json ("style": "file:./style.scss"), but I also had to create a workaround in my local webpack config to transform Sass file extensions to .css in CopyWebpackPlugin. It seems that the automatic version generation code is looking for the style assets defined in the input block.json file, but if you're using a Sass file and have .css in block.json that file doesn't exist. See

10up-toolkit/packages/toolkit/utils/blocks.js

Lines 48 to 57 in 4c4ba03

if (!hasVersion && isFilePath) {
styleArray.forEach((rawStylePath) => {
if (!rawStylePath.startsWith('file:')) {
return;
}
const stylePath = rawStylePath.replace('file:', '');
const absoluteStylePath = path.join(absoluteDirectory, stylePath);
styleFileContentHash += getFileContentHash(absoluteStylePath);
});
}
@nicholasio I can open a PR if that's cool. My fix would be to treat Sass files the same way that TypeScript files are treated, by expecting the source file to be defined in block.json and adding a transform for the file extension within CopyWebpackPlugin.

A PR would be welcomed! Thank you