Using experimentalOptimizeChunks with static and dynamic imports of the same file

[gingur]

• Rollup Version: 1.29.0
• Operating System (or Browser): Windows 10
• Node Version: 10.15.3

How Do We Reproduce?

Code REPL

Setting experimentalOptimizeChunks to true produces the following

entry1.js

'use strict';

var commonEntry = require('./asyncEntry-be86dbf9.js');

console.log('entry1 commonEntry', commonEntry.commonEntry);
new Promise(function (resolve) { resolve(require('./asyncEntry-3be3e543.js')); }).then(asyncEntry => {
  console.log('entry1 asyncEntry', asyncEntry);
});

entry2.js

'use strict';

var commonEntry = require('./asyncEntry-be86dbf9.js');

console.log('entry2 commonEntry', commonEntry.commonEntry);
console.log('entry2 asyncEntry', asyncEntry.asyncEntry$1);

asyncEntry-3be3e543.js

'use strict';

var asyncEntry = require('./asyncEntry-be86dbf9.js');



exports.default = asyncEntry.asyncEntry;

asyncEntry-be86dbf9.js

'use strict';

var commonEntry = 'commonEntryContent';

var asyncEntry = 'asyncEntryContent';

var asyncEntry$1 = /*#__PURE__*/Object.freeze({
	__proto__: null,
	'default': asyncEntry
});

exports.asyncEntry = asyncEntry;
exports.asyncEntry$1 = asyncEntry$1;
exports.commonEntry = commonEntry;

Expected Behavior

The entry1.js file should async require asyncEntry.js, and entry2.js should statically require asyncEntry.js.

Actual Behavior

In entry2.js, the static require statement for asyncEntry.js is completely missing. The identifier for asyncEntry is still used in the code but without the require statment it's resolving to a global that doesn't exist.

[lukastaegert]

Thank you for taking the time to create this issue. Unfortunately, experimentalOptimizeChunks is not only experimental but also largely untested and unmaintained (not to say unmaintainable). There have long been plans to remove it or replace it with a reimplementation. As the latter will take still quite some time, I will remove this feature for Rollup@2, see #3343

It will most likely make a reappearance as a plugin in the future once the necessary changes and APIs have been created.

[frank-dspeed]

@lukastaegert don't do that let it stay its flaged experimental but it is usefull! i know that it comes from ember but still userfull don't remove else i need to fork i don't want that!

[lukastaegert]

But you are aware that it is broken as you can see above? And it is really hard to fix and maintain because it basically tries to incompletely replicate some logic without any connection to that logic. I would be interested to hear what the situation is that you are trying to improve with this feature. Also note that #3305 will land when this feature is removed, which can already noticeably decrease the number of chunks created by dynamic imports. There is another feature planned that will decrease the number of chunks created by static entry points by specifying that some entry points are always loaded before other entry points are loaded.

And of course there is manualChunks, which allows you to paint manually over the chunking today.

[frank-dspeed]

@lukastaegert i am well aware of this but let me show you a good example that it can get used

this is a working workaround for the most bugs of it

const rollup = require('../rollup');

rollup.rollup({
  experimentalCodeSplitting: true,
  optimizeChunks: true,
  input: ['main1.js', 'main2.js', 'main3.js']
}).then(build => {
  return build.generate({ format: 'amd' })
  .then(generated => {
    return build.generate({ format: 'amd' });
  });
}).then(generated => {
  console.log(generated);
})
.catch(e => {
  console.log(e);
})

this does exactly what you want to do in the new implamentation it moves it to the end of the generate phase.

[lukastaegert]

This is not what I mean. The chunking still happens in the build phase, experimentalOptimizeChunks just tries to merge chunks again in the generate phase. And since chunks are complicated objects, this merge is non-trivial and is now proven to be broken in edge cases.

I'm not sure what calling generate twice should accomplish except making everything slower (the optimization is only triggered during the first generate call).

Also, experimentalCodeSplitting has been deprecated for a year now.

[frank-dspeed]

hmm maybe your right and the functionality can be added via hooks anyway so the feature is not needed in the core project

[lukastaegert]

Closed in rollup@2.0.0