Meteor 2.0-beta.4

announce
1

The fourth iteration of meteor 2.0 beta is available and is bringing Tree Shaking with it.

What is it?

Tree-shaking is a technique that the bundler uses to remove unused files and code from the final bundle. This PR implements 2 strategies:

  1. Remove unused Files, by checking es6 imports/exports
  2. Remove unused Exports, by checking imports/exports.

This version still doesn’t implement verification for actual usage in the code. It is restricted to imports, and also deals with dynamic and nested imports.

How to use it?

First, update your meteor version to:

meteor update --release METEOR@2.0-beta.4

Tree shaking comes disabled by default, as Meteor used to rely a lot on global variables, so it’s safer to enable it on demand.

Using inside your app

For enabling tree shaking in your app, simply add the flag:

sideEffects: false

to your package.json.

Using it inside packages

For packages, you can use on package.js the following:

api.setSideEffects(false);

inside the Package.onUse section.
If your package uses api.export(), it will be automatically marked as side-effects true.

Please help us test this, as we can face several non-tested flows, as the static analysis is hard to cover on tests. Don’t forget to leave your feedback on 2.0 PR here: https://github.com/meteor/meteor/pull/11206 or inside Tree-shaking PR itself: https://github.com/meteor/meteor/pull/11164

18 Likes
2

Great work @renanccastro.

This was an extremely difficult task and you nailed it :wink::sunglasses:

1 Like
3

We’re using it. What’s the best way to confirm everything is working as expected treeshaking wise?

1 Like
4

Bundle visualizer before and after?

1 Like
5

I did for our Admin app and there’s no difference in size. So I guess we did our homework manually quite ok.

6

That’s quite a surprise @a4xrbj1… Are you using lodash or anything alike? Make sure you are using lodash-es packages so it can be tree shaked. Commonjs modules are never shaked, so it can be getting into this case. Also, always compare it with it’s minified versions.

@stolinski as @rjdavid said the best way would be to run bundle visualizer before and after (you can disable the flag on package.json to do the test), always running it with --production :wink:

7

No, not using lodash. This is our packages list:

"dependencies": {
  "@babel/runtime": "^7.11.2",
  "@coreui/coreui": "3.3.0",
  "@coreui/coreui-plugin-chartjs-custom-tooltips": "1.3.1",
  "@coreui/icons": "^1.0.1",
  "@popperjs/core": "^2.4.4",
  "babel-eslint": "^10.1.0",
  "bcrypt": "^5.0.0",
  "bootbox": "^5.4.0",
  "bootstrap": "4.5.2",
  "chart.js": "^2.9.3",
  "dayjs": "^1.8.36",
  "flag-icon-css": "3.5.0",
  "font-awesome": "4.7.0",
  "jquery": "3.5.1",
  "meteor-node-stubs": "^1.0.1",
  "pace-progress": "1.0.2",
  "paypal-rest-sdk": "^2.0.0-rc.2",
  "perfect-scrollbar": "1.5.0",
  "popper.js": "1.16.1",
  "request": "^2.88.2",
  "request-promise": "^4.2.6",
  "simple-line-icons": "^2.5.5",
  "toastr": "^2.1.4"
},
8

I’m hitting https://github.com/meteor/meteor/issues/11231 on Beta 4 without treeshaking enabled.

9

I just gave Meteor 2.0-beta.4 a shot, no noticeable problems either in development or deployed to ubuntu (yay!), however my bundle size before and after is the same built for either mac or linux.

Screen Shot 2020-11-13 at 9.10.56 AM

10

I have our dev team all using beta4, and we are seeing high memory usage (~2.4G) this happens quite quickly (ie it’s probably not a memory leak over time). Performance isn’t good, but that may be related to the high memory usage

11

Some more information - I backtracked to a version of our app from 1 Nov, and did a fresh checkout/build, and memory usage/performance is ok. That was using Meteor 2.0-beta.2. I upgraded it to Meteor 2.0-beta.4 and the problem came back. It could be Meteor 2.0-beta.4, or one of the new packages causing the prob.

12

Who said you should never try beta in production ? https://eval.express :sweat_smile:
So far everything run smooth and tree is shaken :grin:

3 Likes