Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Issue on XMAKE, Error: UMD and IIFE output formats are not supported for code-splitting builds. #1946

Closed
codefactor opened this issue Jul 10, 2020 · 7 comments · Fixed by #2063
Assignees
Labels

Comments

@codefactor
Copy link
Contributor

Describe the bug
I tried upgrading to 0.21.8 and there is an issue in XMAKE which is not happening on my local. I sometimes see this same error on local but only when I accidentally run a build at the same time as the "npm run start" is running and building at the same time.

Log output / Any errors in the console
Check the following logs, let me know if you need a link to XMAKE.

10:44:35 INFO - bundle.es5.js  dist/resources...
10:44:40 INFO - [!] Error: UMD and IIFE output formats are not supported for code-splitting builds.
10:44:40 ERROR - UMD and IIFE output formats are not supported for code-splitting builds.
10:44:40 INFO -     at error (/xmake/j/prod-build10010/w/xweb/xweb-common-webcomponents-PR-linuxx86_64/gen/out/module/node_modules/rollup/dist/shared/node-entry.js:5400:30)
10:44:40 INFO -     at normalizeOutputOptions (/xmake/j/prod-build10010/w/xweb/xweb-common-webcomponents-PR-linuxx86_64/gen/out/module/node_modules/rollup/dist/shared/node-entry.js:14123:20)
10:44:40 INFO -     at getOutputOptionsAndPluginDriver (/xmake/j/prod-build10010/w/xweb/xweb-common-webcomponents-PR-linuxx86_64/gen/out/module/node_modules/rollup/dist/shared/node-entry.js:13910:32)
10:44:40 INFO -     at Object.write (/xmake/j/prod-build10010/w/xweb/xweb-common-webcomponents-PR-linuxx86_64/gen/out/module/node_modules/rollup/dist/shared/node-entry.js:13983:63)
10:44:40 INFO -     at Promise.all.outputOptions.map.output (/xmake/j/prod-build10010/w/xweb/xweb-common-webcomponents-PR-linuxx86_64/gen/out/module/node_modules/rollup/dist/bin/rollup:786:63)
10:44:40 INFO -     at Array.map (<anonymous>)
10:44:40 INFO -     at rollup_js.rollup.then (/xmake/j/prod-build10010/w/xweb/xweb-common-webcomponents-PR-linuxx86_64/gen/out/module/node_modules/rollup/dist/bin/rollup:786:42)
10:44:40 INFO - 
10:44:40 INFO - The script called "build.bundle" which runs "rollup --config config/rollup.config.js --environment ES5_BUILD" failed with exit code 1 https://github.com/sezna/nps/blob/master/other/ERRORS_AND_WARNINGS.md#failed-with-exit-code
10:44:40 INFO - The script called "build" which runs "nps lint prepare build.bundle" failed with exit code 1 https://github.com/sezna/nps/blob/master/other/ERRORS_AND_WARNINGS.md#failed-with-exit-code
10:44:40 INFO - child_process.js:669
10:44:40 INFO -     throw err;
@vladitasev
Copy link
Contributor

Hello @codefactor ,

We haven't changed anything that might affect rollup. The 0.21.8 release consisted of just standard bugfixes, not directly related to the build.

Could it be that you've recently changed your custom rollup configuration (I noticed you had such in rollup.config.js)? Could you try, as a test, to just deploy with our default rollup configuration (although it might not work) just to see if you still see that particular error?

Regards,
Vladi

@vladitasev vladitasev self-assigned this Jul 17, 2020
@codefactor
Copy link
Contributor Author

@vladitasev ,

Nothing changes if we revert the changes to the rollup.config.js to the original non-customized version which looks like this:

/* global module */ // (For ESLint...)
module.exports = require("@ui5/webcomponents-tools/components-package/rollup.js");

It really looks like some issue that was introduced in the version change to 0.21.8 - perhaps a small version change in the tools as to what version of rollup is used or something like that.

@vladitasev
Copy link
Contributor

Hi @codefactor ,

I cannot reproduce the issue on my localhost out of the box.

I however debugged rollup's source code and the condition to throw this error lies here:

chunks = yield graph.build(inputOptions.input, inputOptions.manualChunks, inputOptions.inlineDynamicImports);

and then based on chunks length (hasMultipleChunks = chunks.length) we have:

if (hasMultipleChunks) {
        if (outputOptions.format === 'umd' || outputOptions.format === 'iife')
            return error({
                code: 'INVALID_OPTION',
                message: 'UMD and IIFE output formats are not supported for code-splitting builds.'
            });

There are obviously 3 ways to get there:

  • having multiple input entries. This is the most evident one. When I modify the config like this for example: input: {a: "bundle.esm.js", b: "bundle.fake.js"}, I immediately get this error for the ES5 (iife) bundle. However, neither your specific rollup config, nor the original one, have more than one input entries for any of the bundle definitions.
  • having the manualChunks configuration setting (you don't have it, neither the default config)
  • having the inlineDynamicImports configuration setting (you don't have it, neither the default config)

Regarding rollup versions. UI5 Web Components was with 1.23 and common-webcomponents was with 1.32. This didn't seem to make any difference whatsoever. Tested with 1.32 and didn't get the error either. I also tested by running npm run start and then building in parallel but couldn't get the error either.

bundle.mock.js → dist/resources...
152.11 KB
created dist/resources in 8.3s

bundle.esm.js → dist/resources...
141.22 KB
created dist/resources in 7s

bundle.es5.js → dist/resources...
161.06 KB
created dist/resources in 12.4s

Could you add a console.log of your full rollup configuration before exporting it in your custom rollup config file, run the xmake build and paste the result here?

Regards,
Vladi

@allen138
Copy link

Hi @vladitasev,

I found that one of our dependencies, "@xweb/core-utils", was using dynamic imports via the babel plugin "@babel/plugin-proposal-dynamic-import". Current solution is to add the following to the rollup.config.js :

const ES5_CONFIG = rollup.find((config) => /es5\.js$/.test(config.input));
if (ES5_CONFIG) {
  ES5_CONFIG.inlineDynamicImports = true;
}

After adding the above lines, we are able to get a successful build.

Thanks,
Allen

@vladitasev
Copy link
Contributor

Hello @codefactor @allen138

I've debugged quite a bit today and discovered that the error disappears once you remove imports of:
import { getEmploymentItems } from "@xweb/core-utils/src/shell/globalMenus";

For example, a bundle that just imports import "./dist/ArcChart.js"; is fine, but when, say, import "./dist/ContextSwitcher.js"; is imported, the error appears.

Stripping down its imports one by one, I found that the error appears when this import is added:
import { getEmploymentItems } from "@xweb/core-utils/src/shell/globalMenus";

I'll investigate further tomorrow, but this might give you some clue in the meantime

Regards

@vladitasev
Copy link
Contributor

I would suggest that you use the following config:

rollup = [
		{
			...rollup[0],
			input: "bundle.mock.js"
		},
		rollup[0],
		{
			...rollup[1],
			inlineDynamicImports: true
		}
	]

which basically enforces inlineDynamicImports for the ES5 build. We can even hard-code this in our official rollup config file. Thus, when you have dynamic imports, the IE build will not fail (and of course at runtime IE won't benefit from bundle chunks, as there will be a single big bundle with all dynamic imports treated as standard ones).

@codefactor
Copy link
Contributor Author

@vladitasev ,

Thanks for tracking down the particular import that introduces the need for code splitting. The import for globalMenus.js includes transitively the security.js which is the one that does the dynamic import to some hashing JS code that is not always needed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants