Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cant compile block after installing via @wordpress/create-block #38526

Closed
markcummins opened this issue Feb 4, 2022 · 8 comments · Fixed by #38584
Closed

Cant compile block after installing via @wordpress/create-block #38526

markcummins opened this issue Feb 4, 2022 · 8 comments · Fixed by #38584
Assignees
Labels
Good First Issue An issue that's suitable for someone looking to contribute for the first time Needs Dev Ready for, and needs developer efforts [Package] Scripts /packages/scripts [Type] Bug An existing feature does not function as intended
Projects

Comments

@markcummins
Copy link

markcummins commented Feb 4, 2022

Description

I am trying to create a Block by running 'npx @wordpress/create-block demo'.

The block fails to compile though, with the following output:

`Creating a new WordPress plugin in "demo" folder.

Creating a "block.json" file.

Creating a "package.json" file.

Installing @wordpress/scripts package. It might take a couple of minutes...

Formatting JavaScript files.

Compiling block.
/home/mark/.npm/_npx/0890e296436e9575/node_modules/execa/lib/error.js:59
error = new Error(message);
^

Error: Command failed with exit code 2: npm run build
[webpack-cli] Invalid configuration object. Webpack has been initialized using a configuration object that does not match the API schema.

  • configuration.entry should be one of these:
    function | object { : [non-empty string, ...] (should not have fewer than 1 item, should not have duplicate items) | non-empty string | object { import, asyncChunks?, chunkLoading?, dependOn?, filename?, layer?, library?, publicPath?, runtime?, wasmLoading? } } | [non-empty string, ...] (should not have fewer than 1 item, should not have duplicate items) | non-empty string
    -> The entry point(s) of the compilation.
    Details:
    • configuration.entry['wp-content/plugins/demo/'] should be one of these:
      [non-empty string, ...] (should not have fewer than 1 item, should not have duplicate items) | non-empty string
      -> Module(s) that are loaded upon startup.
      Details:
      • configuration.entry['wp-content/plugins/demo/'] should be an array:
        [non-empty string, ...] (should not have fewer than 1 item, should not have duplicate items)
        -> All modules are loaded upon startup. The last one is exported.
      • configuration.entry['wp-content/plugins/demo/'] should be a non-empty string.
        -> The string is resolved to a module which is loaded upon startup.
    • configuration.entry['wp-content/plugins/demo/'] should be an object:
      object { import, asyncChunks?, chunkLoading?, dependOn?, filename?, layer?, library?, publicPath?, runtime?, wasmLoading? }
      -> An object with entry point description.
    • configuration.entry['wp-content/plugins/demo/'] should be one of these:
      [non-empty string, ...] (should not have fewer than 1 item, should not have duplicate items) | non-empty string | object { import, asyncChunks?, chunkLoading?, dependOn?, filename?, layer?, library?, publicPath?, runtime?, wasmLoading? }
      -> An entry point with name.`

I have tried using different config settings in @wordpress/create-block and different versions of node (versions 12, 14, 15, 16). I have searched online to see if I could find anyone else with a similar issue but can't find any similar issues.

I don't think it should make a difference but I am also running Wordpress from a docker container.

Step-by-step reproduction instructions

  1. nvm use 15 (Outputs: Now using node v15.14.0 (npm v7.7.6))
  2. npx @wordpress/create-block demo

Screenshots, screen recording, code snippet

No response

Environment info

  • PHP version: 7.4.23
  • node v15.14.0
  • npm v7.7.6
  • OS: Linux 5.4.0-96-generic 109-Ubuntu SMP Wed Jan 12 16:49:16 UTC 2022 x86_64
  • WordPress 5.9 running Twenty Twenty-One theme
  • @wordpress/create-block 2.8.0

Please confirm that you have searched existing issues in the repo.

Yes

Please confirm that you have tested with all plugins deactivated except Gutenberg.

Yes

@skorasaurus skorasaurus added [Package] Create Block /packages/create-block Needs Testing Needs further testing to be confirmed. labels Feb 4, 2022
@skorasaurus
Copy link
Member

Hi,

Just to be sure, is the error message exactly the same on node 16?

@skorasaurus skorasaurus added the [Status] Needs More Info Follow-up required in order to be actionable. label Feb 4, 2022
@gziolo gziolo added the [Package] Scripts /packages/scripts label Feb 4, 2022
@markcummins
Copy link
Author

Thanks, yes its the same with 16 for me. After I run npx @wordpress/create-block demo, I can retry the compiler with npm run build. When I do that, I get the exact same error.

However if I go to node_modules/@wordpress/scripts/config/webpack.config.js and comment out line 89 entry: getWebpackEntryPoints(), and rerun npm run build, then the compiler does seem to work

@markcummins
Copy link
Author

markcummins commented Feb 5, 2022

Ok I figured out the issue.

The path that my WordPress directory is '/home/mark/Development/www/WordPress/src/wp-content/plugins/demo/src/index.js'.

The Webpack file tries to extract the filename by splitting the path between src and .js, but because my WordPress install is located in a folder called src, that function returns an array instead of a string.

So the soultion for me is to rename the 'src' directory that my WordPress install is located in.

The function is in config.js here in case you think it needs to be addressed, but it might be an edge case.

// Takes the path without the file extension, and relative to the src directory. const [, entryName] = filepath .split('.')[0] .split('src/'); if (!entryName) { return; }

@skorasaurus skorasaurus removed [Status] Needs More Info Follow-up required in order to be actionable. Needs Testing Needs further testing to be confirmed. labels Feb 5, 2022
@skorasaurus
Copy link
Member

skorasaurus commented Feb 5, 2022

Ok I figured out the issue.

The path that my WordPress directory is '/home/mark/Development/www/WordPress/src/wp-content/plugins/demo/src/index.js'.

The Webpack file tries to extract the filename by splitting the path between src and .js, but because my WordPress install is located in a folder called src, that function returns an array instead of a string.

So the soultion for me is to rename the 'src' directory that my WordPress install is located in.

The function is in config.js here in case you think it needs to be addressed, but it might be an edge case.

// Takes the path without the file extension, and relative to the src directory. const [, entryName] = filepath .split('.')[0] .split('src/'); if (!entryName) { return; }

Interesting find; thanks for sharing, and glad it worked out for you! It's an interesting edge case but worth pinging @gziolo what his thoughts are.

@gziolo
Copy link
Member

gziolo commented Feb 6, 2022

I will provide the fix tomorrow. Thank you for the report and sharing your findings. It sounds like an edge case but we surely should avoid it. 👍

I can imagine it also working incorrectly when you would reference a file in your plugin outside of the inner src folder but it would detect the path based on the outer src folder 🙈

@gziolo gziolo added [Type] Bug An existing feature does not function as intended and removed [Package] Create Block /packages/create-block labels Feb 6, 2022
@gziolo gziolo added this to To do in Core JS Feb 6, 2022
@gziolo gziolo added Needs Dev Ready for, and needs developer efforts Good First Issue An issue that's suitable for someone looking to contribute for the first time labels Feb 6, 2022
@github-actions github-actions bot added the [Status] In Progress Tracking issues with work in progress label Feb 7, 2022
@gziolo
Copy link
Member

gziolo commented Feb 7, 2022

I opened #38584 that should address it.

@markcummins
Copy link
Author

Perfect, thank you for working on this.

@gziolo gziolo moved this from To do to Done in Core JS Feb 8, 2022
@gziolo gziolo removed the [Status] In Progress Tracking issues with work in progress label Feb 8, 2022
@gziolo
Copy link
Member

gziolo commented Feb 8, 2022

It should be published to npm on Thursday at the latest.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Good First Issue An issue that's suitable for someone looking to contribute for the first time Needs Dev Ready for, and needs developer efforts [Package] Scripts /packages/scripts [Type] Bug An existing feature does not function as intended
Projects
No open projects
Core JS
  
Done
Development

Successfully merging a pull request may close this issue.

3 participants