Could you explain what that means, please?
I am sorry for bad wording.
I realized that meteor has its own babel-plugins that transform import-statements. E.g. when using the bable-preset 2015 or “env” you will experience some issues. See also this comment from benjamin: https://github.com/meteor/meteor/issues/8724#issuecomment-304699767
That might be a reason why babel-plugin-lodash does not work in meteor, but honestly, i never tracked this down. I know that babel-plugin-lodash works when you are using a non-meteor-project (e.g. when you write a npm-package).
2 Likes
SSR would be definitely be a big win. It’s on the list. But unfortunately seems to require switching from Flow Router to React Router because flow-router-ssr was abandoned and didn’t work after switching to container based subscriptions. SSR alternative to abandoned flow-router-ssr? (React) (Also received a DM from somone in a similar bind.)
I’m definitely open to ideas on this!
I’m split between wanting to follow Meteor’s recommended solution (flow router), which is working splendidly otherwise, or switching to react router and the, imo, not-great JSX syntax for routing and not a Meteor recommended package.
Chrome 59 dev tools will show unused JS & CSS! Allows insight into how much benefit JS tree shaking would bring to the app!
1 Like
Maybe drop a line into this issue? It seems like the maintainers there are looking for feedback regarding SSR.
1 Like
Wow! Using Chrome Dev tools, I can see 37% of my JS bundle is never executed at all! Tree shaking is going to be great, if it reduces some/most of that.
My bundle could theoretically decrease from 1,038 kb > 651 kb before gzip.
(To check you JS bundle: Upgrade to Chrome 59. Click for the JS bundle in the Sources tab. Hold Ctrl + Shift + P and type for “coverage” to enable it and then click Record. Reload if needed.)
4 Likes
Can this be achieved through an API somewhere?
You mean an API within Meteor? Not that I’m aware of yet.
Yeah, I am getting the same thing. I think I may be naively using another module that imports the entire lodash module, though… gonna have to do some digging.
1 Like
I somehow get the feeling that 1.5 is going to make Meteor better in general because all the dirty details now surface because of the bundle stats and visualizer.
And I like it 
6 Likes
I’m still a little unclear about all the tools that allow us to surface the details, will you or someone explain, using Meteor 1.5 and Chrome, how we visualize and parse this?
Have you tried the bundle visualizer yet? Basically it shows you up front what is taking up space in your app.
Thanks for answering. No, I have not. How do I get to that, is that in Chrome?
Thanks. This the bundle-visualizer is only available in 1.5 or can I use it now in 1.3.5.1? It looks like there is no version requirement from the docs.
Sorry, I based on that on this context you used here previously when asking how to use it. It’s only for 1.5 and it will not work on older versions of Meteor.
2 Likes
Looking at your package list, I know offhand that meteorhacks:inject-data contains a dependency on jquery. This was a gotcha for me earlier.
To get rid of it, I had to do a quick and dirty fix where I cloned it locally to remove the dependency myself.
1 Like
That’s awesome! Thank you so much! I see there are old unmerged PRs to remove jquery as a dep from meteorhacks:inject-data.
How did you get your edited meteorhacks:inject-data used in your app, given it’s a dep of a meteor package? (If it were an NPM package, it’d be clear, but it’s a dep of a meteor package.)