Fixes #11949: Error: The block "xxx" can have a maximum of 3 keywords.

[jameelmoses]

Description

Fixes: #11949
Instead of failing to register a block if more than 3 keywords are given, only return the first 3 by slicing the keywords array.

How has this been tested?

npm run lint

Types of changes

Bug fix (non-breaking change which fixes an issue)

Checklist:

• My code is tested.
• My code follows the WordPress code style.
• My code follows the accessibility standards.
• My code has proper inline documentation.

[gziolo]

@jameelmoses thanks for your contribution. The change that was introduced causes one of the unit tests to fail. You can run locally npm run test-unit to find out more details. It has to be updated to reflect code changes.

The changes proposed in this PR look good and it seems like a good compromise. I would be happy to get another opinion from @aduth or @youknowriad.

[jameelmoses]

@gziolo I ran unit tests, and 2 failed but they are seemingly unrelated to my changes.

  babel-plugin
    .isValidTranslationKey()
      ✓ should return false if not one of valid keys (3ms)
      ✓ should return true if one of valid keys (1ms)
    .isSameTranslation()
      ✓ should return false if any translation keys differ (3ms)
      ✓ should return true if all translation keys the same (1ms)
    .getTranslatorComment()
      ✕ should not return translator comment on same line but after call expression (494ms)
      ✓ should return translator comment on leading comments (11ms)
      ✓ should be case insensitive to translator prefix (3ms)
      ✓ should traverse up parents until it encounters comment (16ms)
      ✓ should not consider comment if it does not end on same or previous line (3ms)
      ✓ should use multi-line comment starting many lines previous (9ms)
    .getNodeAsString()
      ✓ should returns an empty string by default (5ms)
      ✓ should return a string value (3ms)
      ✓ should be a concatenated binary expression string value (4ms)

  ● babel-plugin › .getTranslatorComment() › should not return translator comment on same line but after call expression

    expect(jest.fn()).not.toHaveWarned(expected)

    Expected mock function not to be called but it was called with:
    ["Browserslist: caniuse-lite is outdated. Please run next command `npm update caniuse-lite browserslist`"]

      32 | 	function assertExpectedCalls() {
      33 | 		if ( spy.assertionsNumber === 0 && spy.mock.calls.length > 0 ) {
    > 34 | 			expect( console ).not[ matcherName ]();
         | 			^
      35 | 		}
      36 | 	}
      37 |

      at Object.assertExpectedCalls (packages/jest-console/src/index.js:34:4)

 FAIL  packages/babel-preset-default/test/index.js
  Babel preset default
    ✕ transpilation works properly (964ms)

  ● Babel preset default › transpilation works properly

    expect(jest.fn()).not.toHaveWarned(expected)

    Expected mock function not to be called but it was called with:
    ["Browserslist: caniuse-lite is outdated. Please run next command `npm update caniuse-lite browserslist`"]

      32 | 	function assertExpectedCalls() {
      33 | 		if ( spy.assertionsNumber === 0 && spy.mock.calls.length > 0 ) {
    > 34 | 			expect( console ).not[ matcherName ]();
         | 			^
      35 | 		}
      36 | 	}
      37 |

      at Object.assertExpectedCalls (packages/jest-console/src/index.js:34:4)```

[gziolo]

The udated version of the code removes the check for keywords completely which is different than the initial proposal. I don’t think this is expected API change.

This PR still have some merge conflicts so that migt why those unrelated tests fail.

[aduth]

I don’t think this is expected API change.

I proposed the change at #11949 (comment) .

I'd welcome your feedback if you have any reservations, though.

[gziolo]

I missed the discussion in the issue and I reviewed based on the previous agreement. I’m fine with your proposal applied in this PR as is. Let’s make sure thete are no merge conflicts and proceed with what we have at the moment 👍 This might help to close similar PRs 😃

[aduth]

I did a cursory review of the codebase to ensure there were no other references to the three-keyword maximum.

I found a reference as part of the @wordpress/rich-text package, but I believe this to be an entirely separate thing, though presumably inspired by the blocks implementation. We should probably bring this into alignment, though I don't think it ought to block the work here (cc @iseulde).

gutenberg/packages/rich-text/src/register-format-type.js

Lines 118 to 123 in a615ce6

	if ( 'keywords' in settings && settings.keywords.length > 3 ) {
	window.console.error(
	'The format "' + settings.name + '" can have a maximum of 3 keywords.'
	);
	return;
	}

As @gziolo noted, there are merge conflicts to resolve, but otherwise the changes look good to me.

[gziolo]

I opened #13848 to resolve merge conflicts and merge this PR into master. @jameelmoses thanks for your contribution 🎉