Scope strategy of the migration from `create-guten-block` scripts to a `@wordpress/scripts` core setup

[possumbilities]

Problem

Previously:

• 189

The use of create-guten-block as a scaffolding for the WordPress Gutenberg blocks has a number of compatibility and stability issues. Since the blocks were originally created with create-guten-block core WP has grown its capacity to handle scaffolding, dev, and build. To keep block dev stable long term, create-guten-block needs to be replaced entirely with core functionality.

Description

The entirety of create-guten-block needs to be removed, along with all its dependencies. Its implementation of block structure and file setup is not quite 1:1 compared to the @wordpress/scripts, which will require modification.

Additionally, the CGB setup has its own "cgb" namespace, which is not as intuitive or accurate post deprecation. The namespace should likely shift to "cc" or something similar.

As the namespace will be shifting, that will cause CSS rules, HTML classes, and JS naming conventions to shift as well. This means that any site utilizing a CGB built block will need a proper migration path to using the core scripts implementation with the new namespace and naming convention.

Above all, a proper strategy with adjoining scope needs to be drafted to establish the best migration path.

Implementation

• [x] I would be interested in drafting this plan.

[RonaldRonnie]

hi my senior, do i need to first create the "docker-compose.yml file for building and testing."?

[RonaldRonnie]

Also Migration to @wordpress/scripts:

The README doesn't detail the migration process, it provides context for understanding the current workflow and the commands I'll likely need to modify.

Points for Migration basing on my finding:

npm remains relevant: Since @wordpress/scripts also utilizes npm for managing dependencies and scripts, the basic commands like npm install and npm run will still be used. Build Process Updates: We will likely need to replace the existing build scripts for @wordpress/scripts. WP-CLI remains useful: WP-CLI can still be used within a Docker environment or locally for interacting with WordPress during development and testing.

however, choose a development environment that supports @wordpress/scripts, such as a local WordPress instance with the necessary plugins installed is also crucial.

I requset you to enlight me about this please and to provide me more guidance about it.

[RonaldRonnie]

hi @possumbilities , i've tried out a few changes about this and I would like you go through this file and advise me . I wanted to first work on one file and then proceed . (wp-plugin-creativecommons/src/CC-BY/block.js)

`import './style.scss'; import './editor.scss'; import { __ } from '@wordpress/i18n'; import { registerBlockType } from '@wordpress/blocks'; import { InspectorControls, PanelColorSettings, RichText } from '@wordpress/block-editor';

/**

• Register: CC-BY Gutenberg block.
• Registers a new block provided a unique name and an object defining its
• behavior. Once registered, the block is made available as an option to any
• editor interface where blocks are implemented.
• @link https://wordpress.org/gutenberg/handbook/block-api/
• @param {string} name Block name.
• @param {Object} settings Block settings.
• @return {?WPBlock} The block, if it has been successfully

• registered; otherwise undefined. */ registerBlockType('cc/cc-by', { title: ('CC-BY'), icon: 'media-text', category: 'cc-licenses', keywords: [('creative commons'), ('CC-BY'), ('attribution')], attributes: { bgColor: { type: 'string', default: 'white', }, txtColor: { type: 'string', default: 'black', }, contentName: { selector: '.cc-name', source: 'children', }, contentText: { selector: '.cc-text', source: 'children', }, },

  /**

  • The edit function describes the structure of your block in the context of the editor.
  • This represents what the editor will render when the block is used.
  • The "edit" property must be a valid function.
  • @link https://wordpress.org/gutenberg/handbook/block-api/block-edit-save/
  • @param {Object} props Props.

  • @returns {Mixed} JSX Component. */ edit: function (props) { const { bgColor, txtColor, contentName, contentText } = props.attributes; const { setAttributes } = props;

    const onChangeContentName = contentName => setAttributes({ contentName }); const onChangeContentText = contentText => setAttributes({ contentText });

    return [

    setAttributes({ bgColor: colorValue }), }, { label: __('Text Color'), value: txtColor, onChange: colorValue => setAttributes({ txtColor: colorValue }), }, ]} /> ,
    

    This content is licensed by{' '} Creative Commons Attribution 4.0 International license.

    Edit

    Attribution name (default: This content):

    
    Additional text (optional):
    , ]; },

  /**

  • The save function defines the way in which the different attributes should be combined
  • into the final markup, which is then serialized by Gutenberg into post_content.
  • The "save" property must be specified and must be a valid function.
  • @link https://wordpress.org/gutenberg/handbook/block-api/block-edit-save/
  • @param {Object} props Props.

  • @returns {Mixed} JSX Frontend HTML. */ save: function (props) { const { bgColor, txtColor, contentName, contentText } = props.attributes;

    return ( <div className="message-body" style={{ backgroundColor: bgColor, color: txtColor }}> <img src={${pluginDirUrl}/includes/images/by.png} alt="CC" width="88" height="31" />

    {contentName || 'This content'} is licensed under a{' '} Creative Commons Attribution 4.0 International license. {' '} {contentText}

    </div>

    ); }, }); `