Align module exports with webpack

[JohnDaly]

System Info

System:
OS: macOS 12.4
CPU: (10) arm64 Apple M1 Max
Memory: 22.38 GB / 64.00 GB
Shell: 5.8.1 - /bin/zsh
Binaries:
Node: 20.5.0 - ~/Library/Caches/fnm_multishells/61564_1700104358947/bin/node
Yarn: 1.22.17 - ~/.yarn/bin/yarn
npm: 9.8.0 - ~/Library/Caches/fnm_multishells/61564_1700104358947/bin/npm
pnpm: 8.10.5 - ~/Library/Caches/fnm_multishells/61564_1700104358947/bin/pnpm
bun: 0.8.1 - ~/.bun/bin/bun
Browsers:
Chrome: 119.0.6045.105
Safari: 15.5

Details

I've noticed that rspack build artifacts are typically larger than what webpack generates.

One of the contributing factors is how exports are generated.

Example file:

export const variableWithLongNameOne = 'one';
export const variableWithLongNameTwo = 'two';
export const variableWithLongNameThree = 'three';
export const variableWithLongNameFour = 'four';
export const variableWithLongNameFive = 'five';
export const variableWithLongNameSix = 'six';

webpack will generate the following code:

/*!**********************!*\
  !*** ./src/index.js ***!
  \**********************/
__webpack_require__.r(__webpack_exports__);
/* harmony export */ __webpack_require__.d(__webpack_exports__, {
/* harmony export */   variableWithLongNameFive: () => (/* binding */ variableWithLongNameFive),
/* harmony export */   variableWithLongNameFour: () => (/* binding */ variableWithLongNameFour),
/* harmony export */   variableWithLongNameOne: () => (/* binding */ variableWithLongNameOne),
/* harmony export */   variableWithLongNameSix: () => (/* binding */ variableWithLongNameSix),
/* harmony export */   variableWithLongNameThree: () => (/* binding */ variableWithLongNameThree),
/* harmony export */   variableWithLongNameTwo: () => (/* binding */ variableWithLongNameTwo)
/* harmony export */ });
const variableWithLongNameOne = 'one';
const variableWithLongNameTwo = 'two';
const variableWithLongNameThree = 'three';
const variableWithLongNameFour = 'four';
const variableWithLongNameFive = 'five';
const variableWithLongNameSix = 'six';

rspack generates this code:

__webpack_require__.r(__webpack_exports__);
__webpack_require__.d(__webpack_exports__, {
  variableWithLongNameFive: function() { return variableWithLongNameFive; },
  variableWithLongNameFour: function() { return variableWithLongNameFour; },
  variableWithLongNameOne: function() { return variableWithLongNameOne; },
  variableWithLongNameSix: function() { return variableWithLongNameSix; },
  variableWithLongNameThree: function() { return variableWithLongNameThree; },
  variableWithLongNameTwo: function() { return variableWithLongNameTwo; }
});
 const variableWithLongNameOne = 'one';
 const variableWithLongNameTwo = 'two';
 const variableWithLongNameThree = 'three';
 const variableWithLongNameFour = 'four';
 const variableWithLongNameFive = 'five';
 const variableWithLongNameSix = 'six';

When minified, webpack is able to be compressed more, because the export bindings use () => instead of function(){return}

webpack compressed (pretty formatted for readability):

  e.r(o),
    e.d(o, {
      variableWithLongNameFive: () => n,
      variableWithLongNameFour: () => i,
      variableWithLongNameOne: () => r,
      variableWithLongNameSix: () => l,
      variableWithLongNameThree: () => t,
      variableWithLongNameTwo: () => a,
    });
  const r = 'one',
    a = 'two',
    t = 'three',
    i = 'four',
    n = 'five',
    l = 'six';

rspack compressed (pretty formatted for readability):

n.r(r),
          n.d(r, {
            variableWithLongNameFive: function () {
              return a;
            },
            variableWithLongNameFour: function () {
              return u;
            },
            variableWithLongNameOne: function () {
              return t;
            },
            variableWithLongNameSix: function () {
              return f;
            },
            variableWithLongNameThree: function () {
              return i;
            },
            variableWithLongNameTwo: function () {
              return o;
            },
          });
        let t = 'one',
          o = 'two',
          i = 'three',
          u = 'four',
          a = 'five',
          f = 'six';

For modules that contain lots of exports, this causes the size of rspack to grow quite a bit larger than webpack. Aligning with webpack would lead to more optimized bundles

Reproduce link

https://github.com/JohnDaly/rspack-export-alignment-with-webpack/

Reproduce Steps

Compare the output between rspack and webpack and notice that webpack has smaller output

[JohnDaly]

Looks like this is the code that will need to be updated:

rspack/crates/rspack_core/src/init_fragment.rs

Line 290 in 96ae293

Ok(format!("{}: function() {{ return {}; }}", prop, s.1))

I think this is the equivalent code from Webpack:
https://github.com/webpack/webpack/blob/7d3a8880036d8e5410a144f4c4c495b8f0e21d88/lib/dependencies/HarmonyExportInitFragment.js#L153-L156

The format of the bindings (either function() { return .. } or () => (..)) is determined based on if the environment supports arrow functions or not
https://github.com/webpack/webpack/blob/7d3a8880036d8e5410a144f4c4c495b8f0e21d88/lib/RuntimeTemplate.js#L133-L137

[hardfist]

try newTreeshaking

[IWANABETHATGUY]

This issue isn't related to tree shaking

[LingyuCoder]

Need full support of runtime template and output.environment, related to #5013.

It is recommended to use gzip for further compression, so that these duplicate function() {} will not significantly affect the size, because they will be retained as the same substring only once.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. If this issue is still affecting you, please leave any comment (for example, "bump"). We are sorry that we haven't been able to prioritize it yet. If you have any new additional information, please include it with your comment!

[daveskybet]

I'm also coming up against this issue, where arrow functions are being converted to function syntax. I'm using newTreeshaking and target setup using browserslist where all browsers in the list support arrow functions.

If it helps, adding this to the minimiser config forces the keeping of arrow functions, however shouldn't be needed:

compress: {
    ecma: 2015,
    unsafe_arrows: true,
},

[stale]

This issue has been automatically marked as stale because it has not had recent activity. If this issue is still affecting you, please leave any comment (for example, "bump"). We are sorry that we haven't been able to prioritize it yet. If you have any new additional information, please include it with your comment!

[dartess]

bump

[hardfist]

@ahabhgk can you confirm whether it's solved?

[isuro]

I've also seen issues where browserslist config wasn't being respected. To get around it, I have to pass targets to env in the swc loader config directly.

[ahabhgk]

I've also seen issues where browserslist config wasn't being respected. To get around it, I have to pass targets to env in the swc loader config directly.

@isuro Do you mean builtin:swc-loader didn't respect the .browserslistrc file? or the runtime code generated by Rspack didn't respect the .browserslistrc file. Would you open an issue and provide a reproduce, it would be very helpful for us to find the potential bug

[isuro]

I think it may be swc-project/swc#3365

[stale]

This issue has been automatically marked as stale because it has not had recent activity. If this issue is still affecting you, please leave any comment (for example, "bump"). We are sorry that we haven't been able to prioritize it yet. If you have any new additional information, please include it with your comment!

[LingyuCoder]

bump

[alvinometric]

Bump from a very eager user of Docusaurus 😁

[victorkirov]

Bump

Our build increased by quite a bit from webpack without the arrow functions. So much so that the switch is potentially going to be held back due to the artifact size ☹