Persistent cache throws warning about build dependency resolution because it's missing a \u0000 char

Bug report

What is the current behavior?

webpack.cache.PackFileCacheStrategy/webpack.FileSystemInfo] Resolving '.pnpm/es5-ext@0.10.53/node_modules/es5-ext/array/#/clear' in /Users/scamden/creditiq/uno/common/temp/node_modules/.pnpm/es6-iterator@2.0.3/node_modules/es6-iterator for build dependencies doesn't lead to expected result '/Users/scamden/creditiq/uno/common/temp/node_modules/.pnpm/es5-ext@0.10.53/node_modules/es5-ext/array/#/clear.js', but to '/Users/scamden/creditiq/uno/common/temp/node_modules/.pnpm/es5-ext@0.10.53/node_modules/es5-ext/array/#/clear.js' instead. Resolving dependencies are ignored for this path.

warning on writing persistent cache in development mode if the dep has a # in the path and has already been loaded by node prior to dependency resolution for the cache.

If the current behavior is a bug, please provide the steps to reproduce.

https://github.com/creditiq/simple-repros/tree/webpack-cache-resolution-warning

Repro:

1. Clone the above
2. npm i
3. cd nested
4. npm run build

(note: this branch also contains a repro for bug: https://github.com/webpack/webpack/issues/12156, if you do the same steps but replace step 3 with cd \#nested)

Result: warning above

Expected: no warning

I have tracked the bug down to a \u0000 in the resolved result (that was added by webpack code when escaping the # one stack frame above the warning) that is not there in the job.expected value.

The expected value in my case was resolved via the require.cache inside the RBDT_FILE_DEPENDENCIES job as a RBDT_RESOLVE_CJS_FILE_AS_CHILD. I checked every path and child path one level deep in that cache and not one value had a \u0000 in it so I’m guessing the fix is to escape # with \0 when the file was found in the require.cache, but the code is a bit over my head so hopefully this lead gives someone more familiar a light bulb. Maybe alternatively the expected and result values should be compared with any \0 stripped out. Hopefully a maintainer will know 😬 I’ve made a PR https://github.com/webpack/webpack/pull/13149 for the latter because it feels lower risk, but if the right solution is to add escaping to paths found in the require.cache, I’m happy to do that instead 😃

webpack version: 5.31.0 Node.js version: 14.16.0 Operating System: Mac OS X Catalina Additional tools:

[scamden]

@alexander-akait ok tried again. this fixes both bugs but it does seem odd to have to reverse this intentional escaping…

[scamden]

Cool. Closed it. Just a stab 😃 not 100% sure this is a dupe though because I’m not seeing any problem resolving… or maybe it wouldn’t resolve when it goes to validate the cache later?

It seems like these \0’s are added on purpose by enhanced-resolver but I’m not sure why or where they are meant to be removed / how they are intended not to break resolution. I can dig in a little further if it will help resolve this quicker (no pun intended) but I’m very unfamiliar with this code.

Let me know if you think it’s worth my time or if I should just wait for a core maintainer to fix this.