Version 2.23.1 of rollup-commonjs is the last one that works properly without triggering runtime errors. I've managed to upgrade to the latest version but it appears that something in the mammoth PR rollup/rollup/pull/3710 breaks object-shorthand assignments so in a few cases we have to write messy code like this from Notifications.vue:
import { tooltipDelay } from "../../common/Timings";
export default {
data: () => ({
tooltipDelay: tooltipDelay // short-hand assignment breaks rollup-commonjs (gets converted to something like common.x)
}),
No value of output.interop makes a difference and neither does externalLiveBindings: false or freeze: false.
The bug occurs even when Terser is disabled so doesn't appear to be a simple re-ordering of when that optimisation gets executed. I wonder if it relates to various rollup commits that reference "de-optimisation". Something is perhaps no longer being de-optimised like it used to be.
Runtime errors introduced by build tooling are never fun but since I've found a workaround I can postpone further investigation for the time being.
Version 2.23.1 of rollup-commonjs is the last one that works properly without triggering runtime errors. I've managed to upgrade to the latest version but it appears that something in the mammoth PR rollup/rollup/pull/3710 breaks object-shorthand assignments so in a few cases we have to write messy code like this from Notifications.vue:
No value of output.interop makes a difference and neither does externalLiveBindings: false or freeze: false.
The bug occurs even when Terser is disabled so doesn't appear to be a simple re-ordering of when that optimisation gets executed. I wonder if it relates to various rollup commits that reference "de-optimisation". Something is perhaps no longer being de-optimised like it used to be.
Runtime errors introduced by build tooling are never fun but since I've found a workaround I can postpone further investigation for the time being.