fix(build): support running Blocky locally on Windows machines

[abdul-alhasany]

The basics

• I branched from develop
• My pull request is against develop
• My code follows the style guide
• I ran npm run format and npm run lint

The details

Resolves

#6864 and #7097

Fixes

Proposed Changes

Make building process compatible with machines run on windows.

Behavior Before Change

When running npm run start errors occur as described in the bug reports above.

Behavior After Change

Running npm run start is working with no errors on Windows.

Reason for Changes

Help developers who work on Windows machines to run blocky locally and potentially contribute to the codebase.

Test Coverage

I did not create any tests. I tested the code on my Windows machine.

Documentation

I don't think any further documentation required for this change. Current documentation already asks users to run npm run start. The user does not need to do anything specific on Windows machines.

Additional Information

No

[google-cla]

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

[rachel-fenichel]

This looks right to me and tests pass. @cpcallen can you double-check the chunking command in the last file?

[cpcallen]

Hi @abdul-alhasany! Thanks for this pull request. We especially appreciate external developers who use Windows helping us with issues like this because we've not had any frequent Windows users on the core Blockly team for some time. I'm only sorry that I didn't have time to look at it until now.

Do have a look at my comments, questions and suggested changes below, and let me know if there is anything that is not clear.

[cpcallen]

What I'm unclear about—and what would be very helpful if you could give us some information about—is what the strings in the chunkFiles array look like.

On macOS (and Linux etc.) they use / as a separator, and I was expecting that they would use \ on win32, and so using f.endsWith(path.sep + chunk.entry) (where chunk.entry also uses path.sep) should work fine.

But from this proposed code change it seems that for chunkFiles uses / as a path separator even on Windows. Is that correct?

In any case, the proposed change can be simplified somewhat, since path.sep is only ever either '/' or '\\':

Suggested change

	chunk => chunkFiles.find(f => {
	return f.endsWith(path.sep.replace("\\", "/") + chunk.entry.replaceAll("\\", "/"));
	}
	));
	chunk => chunkFiles.find(f => f.endsWith('/' + chunk.entry.replaceAll("\\", "/")));

[abdul-alhasany]

Windows accepts both \ and / which is why, in my projects, I generally opt in for path.replaceAll("\\", "/") to make the behavior consistent across os systems. The reason I also did not replace path.sep is because I did not want to introduce extra changes. I wanted to keep the original code the same as much as possible.

There are all chunk entries that pass the condition (f.endsWith):

build\src\core\main.js
build\src\blocks\blocks.js
build\src\generators\javascript.js
build\src\generators\python.js
build\src\generators\php.js
build\src\generators\lua.js
build\src\generators\dart.js

[cpcallen]

Please run npm run format to fix formatting issues.

[abdul-alhasany]

build_task.js is ignored by .eslintignore. What formatting issues are there? I can do it manually if it is required.

[cpcallen]

build_task.js is ignored by .eslintignore. What formatting issues are there? I can do it manually if it is required.

Our lint checks are configured specifically not to do formatting checks, which are done by a separate GitHub workflow (action). I thought I had seen a format check failure due to the double quotes, but apparently either I was mistaken or the failure was transitory, as I see it is now passing.

Nevertheless, please fix quoting as noted.

[abdul-alhasany]

No problem. All done.