Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Fix `npm run docs:build` on Windows environments #16029
Windows environments do not support shebang (#!) scripts. This caused
The fix is to run
I tested this by starting a Windows environment in VirtualBox, installing Node.js, downloading Gutenberg, and then running:
The command exited without error.
requested review from
Jun 7, 2019
Thanks a lot for taking a look at this issue @noisysocks. For what it's worth, I made changes to the two files you provided here and ran
I'm not entirely sure if this is related, but wanted to mention it here in case it's helpful.
Thanks a ton for troubleshooting this with me @noisysocks. The good news on this front is that with your latest change
diff --git a/docs/designers-developers/developers/data/data-core-block-editor.md b/docs/designers-developers/developers/data/data-core-block-editor.md index 6e496446d..cebbb128c 100644 --- a/docs/designers-developers/developers/data/data-core-block-editor.md +++ b/docs/designers-developers/developers/data/data-core-block-editor.md @@ -8,812 +8,247 @@ Namespace: `core/block-editor`. <a name="canInsertBlockType" href="#canInsertBlockType">#</a> **canInsertBlockType** -Determines if the given block type is allowed to be inserted into the block list. - -_Parameters_ - -- _state_ `Object`: Editor state. -- _blockName_ `string`: The name of the block type, e.g.' core/paragraph'. -- _rootClientId_ `?string`: Optional root client ID of block list. - -_Returns_ - -- `boolean`: Whether the given block type is allowed to be inserted. +Undocumented declaration. <a name="getAdjacentBlockClientId" href="#getAdjacentBlockClientId">#</a> **getAdjacentBlockClientId** -Returns the client ID of the block adjacent one at the given reference -startClientId and modifier directionality. Defaults start startClientId to -the selected block, and direction as next block. Returns null if there is no -adjacent block. - -_Parameters_ - -- _state_ `Object`: Editor state. -- _startClientId_ `?string`: Optional client ID of block from which to search. -- _modifier_ `?number`: Directionality multiplier (1 next, -1 previous). - -_Returns_ - -- `?string`: Return the client ID of the block, or null if none exists. +Undocumented declaration. <a name="getBlock" href="#getBlock">#</a> **getBlock** -Returns a block given its client ID. This is a parsed copy of the block, -containing its `blockName`, `clientId`, and current `attributes` state. This -is not the block's registration settings, which must be retrieved from the -blocks module registration store. - -_Parameters_ - -- _state_ `Object`: Editor state. -- _clientId_ `string`: Block client ID. - -_Returns_ - -- `Object`: Parsed block object. +Undocumented declaration. <a name="getBlockAttributes" href="#getBlockAttributes">#</a> **getBlockAttributes** -Returns a block's attributes given its client ID, or null if no block exists with -the client ID. - -_Parameters_ - -- _state_ `Object`: Editor state. -- _clientId_ `string`: Block client ID. - -_Returns_ - -- `?Object`: Block attributes. +Undocumented declaration. <a name="getBlockCount" href="#getBlockCount">#</a> **getBlockCount** -Returns the number of blocks currently present in the post. - -_Parameters_ - -- _state_ `Object`: Editor state. -- _rootClientId_ `?string`: Optional root client ID of block list. - -_Returns_ - -- `number`: Number of blocks in the post. +Undocumented declaration.
In case you need it, here are the details of my setup:
Both Node and NPM were installed directly on Windows, not using Windows Subsystem for Linux.
Let me know if there is anything else you think I can do at this point. Thanks again.
Hey, sorry for the delay to respond (I was AFK).
I took the liberty to push a couple of minor changes for consistency and to make sure this also works when the tasks are executed via git pre-commit hook.
@jg314 would you mind testing these 3 scenarios?
I think this is ready to go, I just want to make sure everything is fine after the changes I made.
@nosolosw, unfortunately, it didn't work. Step 1 to run
I'm not sure if this matters to you all, but I figured it's worth mentioning that Step 1 I mentioned above only works if none of the directories where this code lives has a space in it. If it does, running
Let me know what else I can do to help.
It sounds like there were linebreaks errors, unrelated to the doc changes.
May it be that your editor auto-updates the line endings due to some setting? Perhaps you might look into your editor settings or use a simple one for this test that doesn't do that kind of things (notepad?).
It's definitely possible it was my editor. I'm using Visual Studio Code though so I would be a little nervous to move forward with a solution that doesn't function well with that editor. I'm not basing this on data, but I think it's one of the most popular editors on Windows these days.
You should work with whatever makes you comfortable! :)
I didn't mean you should change your editor forever, but to test this PR without modifying anything else than the JSDoc change. We want to isolate sources of error to make progress. There should be an option in VSCode to set EOL (end of lines) to LF in windows, that should suffice.
Thanks @nosolosw. I definitely didn't think you were telling me to switch editors. I was just worried that if it didn't work for me, then it wouldn't work for anyone else on Windows using Visual Studio Code.
It actually turns out the issue was with my git configuration. I had to run this in the command line to stop git from replacing my line endings:
After making that change I was able to work in Visual Studio Code without any issues and run through steps 1, 2 and 3 successfully.
The only item of note was that for step 2
The last item is the space in the directory names, but I understand if you'd rather not tackle that now.
Let me know what else I can do to help.