This pull request is a first step in a series of pull requests aimed at providing a better structure for sharing code within top-level directories and across top-level directories, with side objectives of flattening directories and creating clearer distinctions of what a module is expected to export. See "Next steps" for more context on what's left to be done.

To inform and justify these changes, the docs/coding-guidelines.md document has been updated with these changes describing the role each dependency serves:

https://github.com/WordPress/gutenberg/blob/71dab6f/docs/coding-guidelines.md#javascript

Effectively this modifies module resolution to the root project directory, encourages relative path imports within a subfolder, and imports across subfolders prefixed by directory name.

Testing instructions:

Ensure the build completes, tests pass, and editor initializes without regressions.

Next steps:

This is a first step in creating a new components directory which will serve as a resource for general-purpose components. We will default to creating components in respective features (like Editable and BlockSwitcher), moved to the top of their directory structure (blocks/editable and editor/block-switcher), and allow them to be extracted or abstracted into general purpose components only when they've proven to serve purpose across multiple features (like components/dashicon).

• Create components top-level directory, moving shared components (Button, Dashicon, IconButton) Add root components directory #736
• Flatten blocks and editor directory, moving components of each up one level Flatten blocks directory #737, Flatten editor directory #739
• Replace wp. global references with respective "WordPress dependency" equivalent Replace wp globals with module equivalents #742
  • Example: wp.i18n.__ to import { __ } from 'i18n';
  • These globals will still be exposed, but not encouraged to be referenced within the Gutenberg project