I cannot seem to find any simple tutorials on this because as soon as I added webpack my app starts to break. Webpack tutorials show how to create a webpack app, but not how to convert from existing one. What advantages do I get from doing so in 1.3?
Do I need to configure webpack.config.js to be in linux with forward slashes or win backward slashes when looking for entry files?
Have you used webpack:webpack package or just added webpack npm package and own webpack config?
If you did second method, you should remove ecmascript and modules from your app if they are already installed: meteor remove modules ecmascript. Webpack will manage all transpaling and bundling for you.
Yes, I would go with webpack:webpack, it’s awesome package which does a lot for you.
I just looked on you issues on github. #157 looks strange, I hope @eXon will be able to reproduce and fix it.
In my current project I’m not using Meteor, so I didn’t try this package with newest Meteor version…
Adding to that, you can split code loading to have faster initial page load, including css splitting. To me that’s very important to let your app scale (in term of code, not user base)
[this is a bit off topic ]
I was wondering the same. Reasons I’ve to stick with Meteor so far are:
awesome data management (publication, reactivity, minimongo)
optimistic UI
simple account/identity management
Arunoda’s incredibly great packages
I got started here (because getting things started with Meteor is a breath), and there’s a cost to change
Reasons that made me wonder if I should use bare Webpack + React + Express + Redux are
very slow build process of Meteor hitting my productivity hard, and MDG seems not to care too much.
It’s been annoying to get webpack / code splitting to work, but other seems to have had a great experience with webpack:webpack, so I might be an edge case.
current MDG focus on things I don’t care much about: Apollo and possibility to use other data sources than Mongo. I’d much rather have great webpack integration and server side rendering since I believe they are now part of what web app should be like, but that’s a very personal opinion.
MDG seems to be pushing for its hosting while I’d rather stay on AWS that has been around for a while, and I’m not sure how my app will scale outside of Meteor’s hosting.
That being said, I’m trying to do as much things that are relying on npm / React / non Meteor stuff as possible in case I need to change, which I really hope I won’t have to.
Agreed. I feel the same on most of these points. I’m not any expert on what the alternative would be to relying on Meteor’s data management - would this be to feed an express.js backed publication into Redux?
I mean meteor remove ecmascript or/and meteor remove modules (https://atmospherejs.com/meteor/modules). You don’t need them because will do transpiling and module management for you.
ecmascript package implies the modules package so usually it’s enough to delete ecmascript which will delete modules as his dependency.