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

CommonJS imports should preserve chained expressions #17723

Closed
bworline opened this issue Oct 3, 2023 · 0 comments · Fixed by #17718
Closed

CommonJS imports should preserve chained expressions #17723

bworline opened this issue Oct 3, 2023 · 0 comments · Fixed by #17718

Comments

@bworline
Copy link
Contributor

bworline commented Oct 3, 2023

Feature request

Similar to Issue #17218, chained calls off of commonjs imports are completely rewritten by webpack.

e.g.,

const ww = require('./es6-module1').obj1["bing"].bang;

generates

const ww = (__webpack_require__(/*! ./es6-module1 */ 960).obj1.bing.bang);

Some optimizing compilers such as the Google Closure Compiler ADVANCED mode and Terser with keep_quoted enabled have a problem with this rewrite. They use the quote notation as a way to say, "hands off" when it comes to minifying variable names so that external interfaces can be preserved. This leads to it seeing x["somevar"] and x.somevar as two different properties, such that x.somevar is minified and x["somevar"] is converted to x.somevar (shorter by one char but not minified). See the Closure docs.

What is the expected behavior?

The expression after the imported object (obj1 in this case) should remain untouched. That is,

const ww = (__webpack_require__(/*! ./es6-module1 */ 960).obj1)["bing"].bang;

What is motivation or use case for adding/changing the behavior?

Get webpack 5 to generate output compatible with the Google Closure Compiler.

How should this be implemented in your opinion?

Factor the code made in #17203 HarmonyImportSpecifierDependency.js into a shared location and call it from CommonJsFullRequireDependency.js as well.

Are you willing to work on this yourself?

Yes. See PR #17718.

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

Successfully merging a pull request may close this issue.

1 participant