prep build 12/31

backport-changelog/6.8/7865.md

@@ -1,3 +1,4 @@
 https://github.com/WordPress/wordpress-develop/pull/7865
 
-* https://github.com/WordPress/gutenberg/pull/66851
+* https://github.com/WordPress/gutenberg/pull/66851
+* https://github.com/WordPress/gutenberg/pull/68174

backport-changelog/6.8/8031.md

@@ -0,0 +1,4 @@
+https://github.com/WordPress/wordpress-develop/pull/8031
+
+* https://github.com/WordPress/gutenberg/pull/66675
+* https://github.com/WordPress/gutenberg/pull/68243

bin/api-docs/gen-components-docs/get-tags-from-storybook.mjs

@@ -0,0 +1,30 @@
+/**
+ * External dependencies
+ */
+import fs from 'node:fs/promises';
+import babel from '@babel/core';
+
+/**
+ * Returns `meta.tags` from a Storybook file.
+ *
+ * @param {string} filePath
+ * @return {Promise<string[]>} Array of tags.
+ */
+export async function getTagsFromStorybook( filePath ) {
+	const fileContent = await fs.readFile( filePath, 'utf8' );
+	const parsedFile = babel.parse( fileContent, {
+		filename: filePath,
+	} );
+
+	const meta = parsedFile.program.body.find(
+		( node ) =>
+			node.type === 'VariableDeclaration' &&
+			node.declarations[ 0 ].id.name === 'meta'
+	);
+
+	return (
+		meta.declarations[ 0 ].init.properties
+			.find( ( node ) => node.key.name === 'tags' )
+			?.value.elements.map( ( node ) => node.value ) ?? []
+	);
+}

bin/api-docs/gen-components-docs/index.mjs

@@ -11,6 +11,7 @@ import path from 'path';
  */
 import { generateMarkdownDocs } from './markdown/index.mjs';
 import { getDescriptionsForSubcomponents } from './get-subcomponent-descriptions.mjs';
+import { getTagsFromStorybook } from './get-tags-from-storybook.mjs';
 
 const MANIFEST_GLOB = 'packages/components/src/**/docs-manifest.json';
 
@@ -113,9 +114,17 @@ await Promise.all(
 			} ) ?? []
 		);
 
+		const tags = await getTagsFromStorybook(
+			path.resolve(
+				path.dirname( manifestPath ),
+				'stories/index.story.tsx'
+			)
+		);
+
 		const docs = generateMarkdownDocs( {
 			typeDocs,
 			subcomponentTypeDocs,
+			tags,
 		} );
 		const outputFile = path.resolve(
 			path.dirname( manifestPath ),

bin/api-docs/gen-components-docs/markdown/index.mjs

@@ -9,26 +9,32 @@ import json2md from 'json2md';
 import { generateMarkdownPropsJson } from './props.mjs';
 
 /**
- * If the string is contentful, ensure that it ends with a single newline.
- * Otherwise normalize to `undefined`.
+ * Converter for strings that are already formatted as Markdown.
  *
- * @param {string} [str]
+ * @param {string} [input]
+ * @return {string} The trimmed input if it is contentful, otherwise an empty string.
  */
-function normalizeTrailingNewline( str ) {
-	if ( ! str?.trim() ) {
-		return undefined;
-	}
-	return str.replace( /\n*$/, '\n' );
-}
+json2md.converters.md = ( input ) => {
+	return input?.trim() || '';
+};
 
-export function generateMarkdownDocs( { typeDocs, subcomponentTypeDocs } ) {
+export function generateMarkdownDocs( {
+	typeDocs,
+	subcomponentTypeDocs,
+	tags,
+} ) {
 	const mainDocsJson = [
 		{ h1: typeDocs.displayName },
 		'<!-- This file is generated automatically and cannot be edited directly. Make edits via TypeScript types and TSDocs. -->',
+		tags.includes( 'status-private' ) && [
+			{
+				p: '🔒 This component is locked as a [private API](https://developer.wordpress.org/block-editor/reference-guides/packages/packages-private-apis/). We do not yet recommend using this outside of the Gutenberg project.',
+			},
+		],
 		{
 			p: `<p class="callout callout-info">See the <a href="https://wordpress.github.io/gutenberg/?path=/docs/components-${ typeDocs.displayName.toLowerCase() }--docs">WordPress Storybook</a> for more detailed, interactive documentation.</p>`,
 		},
-		normalizeTrailingNewline( typeDocs.description ),
+		{ md: typeDocs.description },
 		...generateMarkdownPropsJson( typeDocs.props ),
 	];
 
@@ -39,7 +45,7 @@ export function generateMarkdownDocs( { typeDocs, subcomponentTypeDocs } ) {
 					{
 						h3: subcomponentTypeDoc.displayName,
 					},
-					normalizeTrailingNewline( subcomponentTypeDoc.description ),
+					{ md: subcomponentTypeDoc.description },
 					...generateMarkdownPropsJson( subcomponentTypeDoc.props, {
 						headingLevel: 4,
 					} ),
@@ -49,5 +55,5 @@ export function generateMarkdownDocs( { typeDocs, subcomponentTypeDocs } ) {
 
 	return json2md(
 		[ ...mainDocsJson, ...subcomponentDocsJson ].filter( Boolean )
-	);
+	).replace( /\n+$/gm, '\n' ); // clean unnecessary consecutive newlines
 }

bin/api-docs/gen-components-docs/markdown/props.mjs

@@ -33,7 +33,6 @@ export function generateMarkdownPropsJson( props, { headingLevel = 2 } = {} ) {
 
 			return [
 				{ [ `h${ headingLevel + 1 }` ]: `\`${ key }\`` },
-				prop.description,
 				{
 					ul: [
 						`Type: \`${ renderPropType( prop.type ) }\``,
@@ -42,6 +41,7 @@ export function generateMarkdownPropsJson( props, { headingLevel = 2 } = {} ) {
 							`Default: \`${ prop.defaultValue.value }\``,
 					].filter( Boolean ),
 				},
+				{ md: prop.description },
 			];
 		} )
 		.filter( Boolean );

bin/tsconfig.json

@@ -16,6 +16,7 @@
 		"noEmit": true,
 		"outDir": ".cache"
 	},
+	"include": [],
 	"files": [
 		"./api-docs/update-api-docs.js",
 		"./plugin/config.js",

bin/validate-tsconfig.mjs

@@ -29,14 +29,33 @@ for ( const packageName of packagesWithTypes ) {
 		hasErrors = true;
 	}
 
-	const packageJson = JSON.parse(
-		readFileSync( `packages/${ packageName }/package.json`, 'utf8' )
-	);
-	const tsconfigJson = JSON.parse(
-		stripJsonComments(
-			readFileSync( `packages/${ packageName }/tsconfig.json`, 'utf8' )
-		)
-	);
+	let packageJson;
+	try {
+		packageJson = JSON.parse(
+			readFileSync( `packages/${ packageName }/package.json`, 'utf8' )
+		);
+	} catch ( e ) {
+		console.error(
+			`Error parsing package.json for package ${ packageName }`
+		);
+		throw e;
+	}
+	let tsconfigJson;
+	try {
+		tsconfigJson = JSON.parse(
+			stripJsonComments(
+				readFileSync(
+					`packages/${ packageName }/tsconfig.json`,
+					'utf8'
+				)
+			)
+		);
+	} catch ( e ) {
+		console.error(
+			`Error parsing tsconfig.json for package ${ packageName }`
+		);
+		throw e;
+	}
 	if ( packageJson.dependencies ) {
 		for ( const dependency of Object.keys( packageJson.dependencies ) ) {
 			if ( dependency.startsWith( '@wordpress/' ) ) {

docs/explanations/architecture/styles.md

@@ -37,10 +37,8 @@ The user may change the state of this block by applying different styles: a text
 After some user modifications to the block, the initial markup may become something like this:
 
 ```html
-<p
-	class="has-color has-green-color has-font-size has-small-font-size my-custom-class"
-	style="line-height: 1em"
-></p>
+<p class="has-color has-green-color has-font-size has-small-font-size my-custom-class"
+	style="line-height: 1em"></p>
 ```
 
 This is what we refer to as "user-provided block styles", also know as "local styles" or "serialized styles". Essentially, each tool (font size, color, etc) ends up adding some classes and/or inline styles to the block markup. The CSS styling for these classes is part of the block, global, or theme stylesheets.
@@ -125,7 +123,7 @@ The block supports API only serializes the font size value to the wrapper, resul
 
 This is an active area of work you can follow [in the tracking issue](https://github.com/WordPress/gutenberg/issues/38167). The linked proposal is exploring a different way to serialize the user changes: instead of each block support serializing its own data (for example, classes such as `has-small-font-size`, `has-green-color`) the idea is the block would get a single class instead (for example, `wp-style-UUID`) and the CSS styling for that class will be generated in the server by WordPress.
 
-While work continues in that proposal, there's an escape hatch, an experimental option block authors can use. Any block support can skip the serialization to HTML markup by using `skipSerialization`. For example:
+While work continues in that proposal, there's an escape hatch, an experimental option block authors can use. Any block support can skip the serialization to HTML markup by using `__experimentalSkipSerialization`. For example:
 
 ```json
 {
@@ -134,15 +132,15 @@ While work continues in that proposal, there's an escape hatch, an experimental
 	"supports": {
 		"typography": {
 			"fontSize": true,
-			"skipSerialization": true
+			"__experimentalSkipSerialization": true
 		}
 	}
 }
 ```
 
 This means that the typography block support will do all of the things (create a UI control, bind the block attribute to the control, etc) except serializing the user values into the HTML markup. The classes and inline styles will not be automatically applied to the wrapper and it is the block author's responsibility to implement this in the `edit`, `save`, and `render_callback` functions. See [this issue](https://github.com/WordPress/gutenberg/issues/28913) for examples of how it was done for some blocks provided by WordPress.
 
-Note that, if `skipSerialization` is enabled for a group (typography, color, spacing) it affects _all_ block supports within this group. In the example above _all_ the properties within the `typography` group will be affected (e.g. `fontSize`, `lineHeight`, `fontFamily` .etc).
+Note that, if `__experimentalSkipSerialization` is enabled for a group (typography, color, spacing) it affects _all_ block supports within this group. In the example above _all_ the properties within the `typography` group will be affected (e.g. `fontSize`, `lineHeight`, `fontFamily` .etc).
 
 To enable for a _single_ property only, you may use an array to declare which properties are to be skipped. In the example below, only `fontSize` will skip serialization, leaving other items within the `typography` group (e.g. `lineHeight`, `fontFamily` .etc) unaffected.
 
@@ -154,7 +152,7 @@ To enable for a _single_ property only, you may use an array to declare which pr
 		"typography": {
 			"fontSize": true,
 			"lineHeight": true,
-			"skipSerialization": [ "fontSize" ]
+			"__experimentalSkipSerialization": [ "fontSize" ]
 		}
 	}
 }
@@ -475,7 +473,7 @@ If blocks do this, they need to be registered in the server using the `block.jso
 
 Every chunk of styles can only use a single selector.
 
-This is particularly relevant if the block is using `skipSerialization` to serialize the different style properties to different nodes other than the wrapper. See "Current limitations of blocks supports" for more.
+This is particularly relevant if the block is using `__experimentalSkipSerialization` to serialize the different style properties to different nodes other than the wrapper. See "Current limitations of blocks supports" for more.
 
 #### 3. **Only a single property per block**
 

docs/getting-started/faq.md

@@ -8,7 +8,7 @@ What follows is a set of questions that have come up from the last few years of
 
 “Gutenberg” is the name of the project to create a new editor experience for WordPress — contributors have been working on it since January 2017 and it’s one of the most significant changes to WordPress in years. It’s built on the idea of using “blocks” to write and design posts and pages. This will serve as the foundation for future improvements to WordPress, including blocks as a way not just to design posts and pages, but also entire sites. The overall goal is to simplify the first-time user experience of WordPress — for those who are writing, editing, publishing, and designing web pages. The editing experience is intended to give users a better visual representation of what their post or page will look like when they hit publish. Originally, this was the kickoff goal:
 
-> The editor will endeavour to create a new page and post building experience that makes writing rich posts effortless, and has “blocks” to make it easy what today might take shortcodes, custom HTML, or “mystery meat” embed discovery.
+> The editor will endeavor to create a new page and post building experience that makes writing rich posts effortless, and has “blocks” to make it easy what today might take shortcodes, custom HTML, or “mystery meat” embed discovery.
 
 Key takeaways include the following points:
 

docs/getting-started/fundamentals/javascript-in-the-block-editor.md

@@ -26,7 +26,7 @@ The diagram below provides an overview of the build process when using the `wp-s
 
 - **Production Mode (`npm run build`):** In this mode, `wp-scripts` compiles your JavaScript, minifying the output to reduce file size and improve loading times in the browser. This is ideal for deploying your code to a live site.
 
-- **Development Mode (`npm run start`):** This mode is tailored for active development. It skips minification for easier debugging, generates source maps for better error tracking, and watches your source files for changes. When a change is detected, it automatically rebuilds the affected files, allowing you to see updates in real-time.
+- **Development Mode (`npm start`):** This mode is tailored for active development. It skips minification for easier debugging, generates source maps for better error tracking, and watches your source files for changes. When a change is detected, it automatically rebuilds the affected files, allowing you to see updates in real-time.
 
 The `wp-scripts` package also facilitates the use of JavaScript modules, allowing code distribution across multiple files and resulting in a streamlined bundle after the build process. The [block-development-example](https://github.com/WordPress/block-development-examples/tree/trunk/plugins/data-basics-59c8f8) GitHub repository provides some good examples.
 

docs/reference-guides/block-api/block-edit-save.md

@@ -183,9 +183,34 @@ save: ( { attributes } ) => {
 ```
 
 
-
 When saving your block, you want to save the attributes in the same format specified by the attribute source definition. If no attribute source is specified, the attribute will be saved to the block's comment delimiter. See the [Block Attributes documentation](/docs/reference-guides/block-api/block-attributes.md) for more details.
 
+### innerBlocks
+
+There is a second property in the props passed to the `save` function, `innerBlocks`. This property is typically used for internal operations, and there are very few scenarios where you would need to use it.
+
+`innerBlocks`, when initialized, is an array containing object representations of nested blocks. In those rare cases where you might use this property,
+it can help you adjust how a block is rendered. For example, you could render a block differently based on the number of nested blocks or if a specific block type is present..
+
+
+```jsx
+save: ( { attributes, innerBlocks } ) => {
+	const { className, ...rest } = useBlockProps.save();
+
+	// innerBlocks could also be an object - react element during initialization
+	const numberOfInnerBlocks = innerBlocks?.length;
+	if ( numberOfInnerBlocks > 1 ) {
+		className = className + ( className ? ' ' : '' ) + 'more-than-one';
+	};
+	const blockProps =  { ...rest, className };
+
+	return <div { ...blockProps }>{ attributes.content }</div>;
+};
+```
+
+
+Here, an additional class is added to the block if number of inner blocks is greater than one, allowing for different styling of the block.
+
 ## Examples
 
 Here are a couple examples of using attributes, edit, and save all together.

docs/reference-guides/core-blocks.md

@@ -661,7 +661,7 @@ Contains the block elements used to render a post, like the title, date, feature
 -	**Name:** core/post-template
 -	**Category:** theme
 -	**Ancestor:** core/query
--	**Supports:** align (full, wide), color (background, gradients, link, text), interactivity (clientNavigation), layout, spacing (blockGap), typography (fontSize, lineHeight), ~~html~~, ~~reusable~~
+-	**Supports:** align (full, wide), color (background, gradients, link, text), interactivity (clientNavigation), layout, spacing (blockGap, margin, padding), typography (fontSize, lineHeight), ~~html~~, ~~reusable~~
 
 ## Post Terms