Errors when building on Windows (unable to identify chunk)

[pernyblom]

Check for duplicates

• I have searched for similar issues before opening a new one.

Description

Running 'npm run start' produced the following error on Windows:

[email protected] start
npm run build && concurrently -n tsc,server "tsc --watch --preserveWatchOutput --outDir 'build/src' --declarationDir 'build/declarations'" "http-server ./ -s -o /tests/playground.html -c-1"

[email protected] build
gulp build

[22:52:24] Using gulpfile ~\Documents\GitHub\blockly\gulpfile.js
[22:52:24] Starting 'build'...
[22:52:24] Starting 'buildLangfiles'...
[22:52:24] Finished 'buildLangfiles' after 411 ms
[22:52:24] Starting 'buildJavaScript'...
Unquoted enums in 0 files.
[22:52:34] Finished 'buildJavaScript' after 9.85 s
[22:52:34] Starting 'buildDeps'...
[22:52:38] Finished 'buildDeps' after 3.48 s
[22:52:38] Starting 'buildCompiled'...
[22:52:41] 'buildCompiled' errored after 2.76 s
[22:52:41] Error: Unable to identify chunk
at C:\Users\perny\Documents\GitHub\blockly\scripts\gulpfiles\build_tasks.js:573:23
at Array.map ()
at getChunkOptions (C:\Users\perny\Documents\GitHub\blockly\scripts\gulpfiles\build_tasks.js:558:38)
at buildCompiled (C:\Users\perny\Documents\GitHub\blockly\scripts\gulpfiles\build_tasks.js:646:24)
at bound (node:domain:421:15)
at runBound (node:domain:432:12)
at asyncRunner (C:\Users\perny\Documents\GitHub\blockly\node_modules\bach\node_modules\async-done\index.js:55:18)
at processTicksAndRejections (node:internal/process/task_queues:78:11)
[22:52:41] 'build' errored after 17 s

Looking a little closer on the error, I was able to find the problem.
The chunk.entry had a windows separator (backslash) instead of the slash '/'. This was easy to fix by this thing:
// Convert windows path separators into '/' so that the entrypoint lookup works as intended
const chunkEntries = chunks.map(chunk => chunk.entry.replace(/\/g, '/'));

// Figure out which chunk this is by looking for one of the
// known chunk entrypoints in chunkFiles.  N.B.: O(n*m).  :-(
const chunk = chunks.find(
    (chunk, index) => chunkFiles.find(f => f.endsWith('/' + chunkEntries[index])));

I thought it would be nice to make a PR as well, but it turned out that 1334 files had been modified newlines CRLF, so this was a no go.

Reproduction steps

1. run 'npm run start' on a Windows system

Stack trace

[22:52:41] Error: Unable to identify chunk
    at C:\Users\perny\Documents\GitHub\blockly\scripts\gulpfiles\build_tasks.js:573:23
    at Array.map (<anonymous>)
    at getChunkOptions (C:\Users\perny\Documents\GitHub\blockly\scripts\gulpfiles\build_tasks.js:558:38)
    at buildCompiled (C:\Users\perny\Documents\GitHub\blockly\scripts\gulpfiles\build_tasks.js:646:24)
    at bound (node:domain:421:15)
    at runBound (node:domain:432:12)
    at asyncRunner (C:\Users\perny\Documents\GitHub\blockly\node_modules\bach\node_modules\async-done\index.js:55:18)
    at processTicksAndRejections (node:internal/process/task_queues:78:11)

Screenshots

No response

Browsers

No response

[maribethb]

Hello, thank you for reporting this issue.

I think you can fix this by replacing this line

        chunk => chunkFiles.find(f => f.endsWith('/' + chunk.entry)));

with

        chunk => chunkFiles.find(f => f.endsWith(path.sep + chunk.entry)));

path.sep would use the os-specific path separator instead of assuming it's /. I don't have access to Windows to test this. If you want to try it and it works, if you'd like to open a PR for it that would be great. If it doesn't work please let us know.

---

As a side note, if you are only trying to use Blockly in an application (rather than contribute directly to it or a fork of it), you don't have to build it from scratch yourself. You can download the compiled code from npm or from our github releases.

[maribethb]

Regarding the crlf issue, I'll admit that I'm not all that familiar with this issue having not used windows in the past ~20 years.
I found this helpful article explaining though, and it seems like you can set your git config on your machine to normalize the line endings. Put the setting to true and it will make sure when you stage files, they have the unix-style line endings that blockly expects.

We also don't have a .gitattributes file, but if we did we could solve this problem for all windows developers, as described further down in the article, so that also seems like a reasonable PR if you'd like to make it.

Thanks!

[robeche]

This is still failing...

[email protected] build
gulp build

[11:07:16] Using gulpfile X:\BLOCKLY\gulpfile.js
[11:07:16] Starting 'build'...
[11:07:16] Starting 'buildLangfiles'...
[11:07:17] Finished 'buildLangfiles' after 886 ms
[11:07:17] Starting 'buildJavaScript'...
Unquoted enums in 19 files.
[11:07:24] Finished 'buildJavaScript' after 6.68 s
[11:07:24] Starting 'buildDeps'...
[11:07:26] Finished 'buildDeps' after 2.53 s
[11:07:26] Starting 'buildCompiled'...
[11:07:29] 'buildCompiled' errored after 2.58 s
[11:07:29] Error: Unable to identify chunk
at X:\BLOCKLY\scripts\gulpfiles\build_tasks.js:564:23
at Array.map ()
at getChunkOptions (X:\BLOCKLY\scripts\gulpfiles\build_tasks.js:554:38)
at buildCompiled (X:\BLOCKLY\scripts\gulpfiles\build_tasks.js:637:24)
at bound (node:domain:433:15)
at runBound (node:domain:444:12)
at asyncRunner (X:\BLOCKLY\node_modules\bach\node_modules\async-done\index.js:55:18)
at process.processTicksAndRejections (node:internal/process/task_queues:77:11)
[11:07:29] 'build' errored after 13 s

Any recommendation?
regards!!

[cpcallen]

Reopening this since PR #7127 didn't fix the build error, and didn't address the newline issue at all.

[maribethb]

I've moved the line ending issue to its own issue in #7191

[maribethb]

I had another look at this because there are other areas where we use / instead of path.sep e.g. here (though since the error is not about not being able to find goog.base or the deps file, I'm not sure why these work?)

but more importantly here where we end up writing lines like require(./foo/bar.js). I think this might mean even we didn't get errors about chunk not being found, the UMD wrapper for the chunk might point to an invalid location? Idk, this is stretching the limits of how much I understand this file, so I don't think I'll be able to do anything useful here at the moment. We definitely are not consistent about using path-normalization libraries but I'm not sure where it's important to do so in this file and where it isn't.

[aqtfox]

I've found a temporary workaround on windows:
It looks like the chunkFiles uses / for seperator and chunks uses \. And so because of that .endsWith fails.

Ln. 526 from (\scripts\gulpfiles\build_tasks.js):

chunk => chunkFiles.find(f => f.endsWith(path.sep + chunk.entry)));

to:

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

With this change it successfully builds for me.

[maribethb]

Thank you for the information, @aqtfox !

@cpcallen relevant to a PR you are/were reviewing.

I think instead of using regex we should probably use the path library's normalize capabilities, but I'll leave the details for Christopher's PR review.

[cpcallen]

See PR #7281.

[cpcallen]

I believe this was fixed and is now almost certainly moot since PR #7469 deleted the code in question.