webpack: Crash with `Error: Content and Map of this Source is not available (only size() is supported)`

Bug report

I’m running into Error: Content and Map of this Source is not available (only size() is supported) with Angular.

This seems to have been reported in various other places recently: https://stackoverflow.com/questions/70066980/angular-12-content-and-map-of-this-source-is-not-available-only-size-is-suppo

What is the current behavior?

.../node_modules/webpack-sources/lib/SizeOnlySource.js:16
                return new Error(
                       ^

Error: Content and Map of this Source is not available (only size() is supported)
    at SizeOnlySource._error (.../node_modules/webpack-sources/lib/SizeOnlySource.js:16:10)
    at SizeOnlySource.buffer (.../node_modules/webpack-sources/lib/SizeOnlySource.js:30:14)
    at _isSourceEqual (.../node_modules/webpack/lib/util/source.js:21:51)
    at isSourceEqual (.../node_modules/webpack/lib/util/source.js:43:17)
    at Compilation.emitAsset (.../node_modules/webpack/lib/Compilation.js:4155:9)
    at .../node_modules/webpack/lib/Compiler.js:546:28
    at .../node_modules/webpack/lib/Compiler.js:1127:17
    at eval (eval at create (.../node_modules/tapable/lib/HookCodeFactory.js:33:10), <anonymous>:13:1)
The terminal process "zsh '-c', 'yarn run start'" terminated with exit code: 1.

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

I don’t have a clear reproduction, however I was able to add some logs in emitAsset here, which is part of the stack trace: https://github.com/webpack/webpack/blob/14582fc41504595b04f01561ea19d27391d6b9ac/lib/Compilation.js#L4171-L4176

I added:

	emitAsset(file, source, assetInfo = {}) {
		if (this.assets[file]) {
			try {
				!isSourceEqual(this.assets[file], source);
			} catch (err) {
				console.error(file, this.assets[file], source);
				throw err;
			}

The output before the crash is:

fontawesome-webfont.eot SizeOnlySource { _size: 165742 } RawSource {
  _valueIsBuffer: true,
  _value: <Buffer 6e 87 02 00 ac 86 02 00 01 00 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 00 90 01 00 00 00 00 4c 50 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ... 165692 more bytes>,
  _valueAsBuffer: <Buffer 6e 87 02 00 ac 86 02 00 01 00 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 00 90 01 00 00 00 00 4c 50 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ... 165692 more bytes>,
  _valueAsString: undefined
}

It always seems to crash on the same eot file. Notice that this.assets[file] for this file is a SizeOnlySource.

What is the expected behavior?

No crash.

Other relevant information: webpack version: 5.60.0 Node.js version: 16.13.0 Operating System: MacOS 11.4 Additional tools: Angular 13.0.1

About this issue

  • Original URL
  • State: closed
  • Created 3 years ago
  • Comments: 35 (14 by maintainers)

Most upvoted comments

Currently it’s not happening in my project any more.

But it clears up after removing the cache. It also clears up randomly after messing with package.json dependencies.

However it also randomly comes back. I’ve had this come and go several times over the last few days.

Once it starts happening again I’ll archive the project so I have a reproduction.

@alan-agius4 yes, sure. Let’s schedule a time via Discord.

@andreialecu, is it a possibility to either share your project (privately) or schedule a call so that we can debug this together?

Logic for child compilations is the same as for common compilations, and yes source can be SizeOnlySource if child compilation is cacheable, you can mark modules are not cachable to avoid this problem, but better to store source instead string or buffer, also it will be faster, maybe if you provide example of code I can help

hm, I think you should not store string or buffer, only sources have cache logic, so better to store them and avoid creating sources.RawSource, because it is also bad for performance

Expected, something try to get content there is not content, replaced after writing by webpack, please wait the answer of angular team, we can’t fix it on our side, sorry