UnhandledPromiseRejectionWarning

[dilyanpalauzov]

I use nodejs 13.11.0 with --module option enabled by default (package.json contains {'type': 'module'} and thus all .js files are handled as es6 module), rollup 2.1.0 and rollup-plugin-gzip 2.3.0.

The output is:

(node:18047) UnhandledPromiseRejectionWarning: [rollup-plugin-gzip] Error compressing additional file dest/minified.css
(node:18047) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). To terminate the node process on unhandled promise rejection,
 use the CLI flag `--unhandled-rejections=strict` (see https://nodejs.org/api/cli.html#cli_unhandled_rejections_mode). (rejection id: 2)
(node:18047) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.

The .js file is compressed.

The css file, produced by the same input file, coming from rollup-plugin-css-porter is generated, but not compressed.

[kryops]

Have you tried setting the additionalFilesDelay option to a higher number?

When your CSS file is generated by a different plugin, we cannot determine when the other plugin is finished, so we assume a default delay of 2 seconds. If your CSS file takes longer to generate, it might not be there yet by the time this plugin tries to compress it.

If that doesn't help, could you try and create a minimal reproduction for your problem?

[dilyanpalauzov]

I was wrong, as I misspelled the filenames in additionalFiles vs. the file created by rollup-plugin-css-porter. Aligning the filenames helped.

Isn't the additionalFilesDelay solved now by rollup/rollup#2305 so that its default can be set to 0ms?

[kryops]

@dilyanpalauzov glad you could solve your problem!

You might be right - rollup 2.0.0 removed the old APIs that made this hack necessary.

There is still the possibility that a plugin just writes to the file system directly, so I won't remove the additionalFilesDelay, but disabling it by default sounds like a good idea. I created #9 for that.