Thank you for suggestion but it isn’t what’s causing the error. As the error message says it >cannot resolve the module ‘meteor/meteor’ (‘meteor/collection’, ‘meteor/tracker’, etc. any of Meteor ‘modules’). It errors out even before getting to the contents of ‘meteor/meteor’ to know what exports there are in it. Something to note, I have been using webpack:webpack in the project already from the pre-1.0 versions. The project went through automatic upgrade that webpack:webpack did after installing a post 1.0 version of webpack:webpack. Maybe someone knows how / where webpack:webpack looks for the ‘meteor/…’ modules’ exports? Importing symbols from actual installed npm modules is no problem. That works perfectly. Only Meteor exports cannot be imported from ‘meteor/(anything)’. Thank you for suggestions
I’m struggling with this too. A detailed documentation with the ‘easy way config’ would be great.
In my case, I’m trying get flexboxgrid configured with css modules. Trying get react-flexbox-grid package working with meteor-webpack.
benoitt, thanks for the great work. the package had been working great for me, until I tried to build it into mobile apps. It still builds without any errors, but the app just displays a blank screen, for both ios and android, device or simulator. have you successfully built a mobile app before with the package, or it’s known that it won’t work for building mobile apps? thanks
Did you get it to work eventually?
First @benoitt let me say that I love webpack:wepack because it allows me to use Vue single files components with preprocessors and all.
Here is my question:
Any news about testing? I couldn’t find tests in kickstart examples.
Unit tests with meteor test do not work with webpack. And even if I could make chimp-watch work (not chimp-test) I’m considering using Karma to have a single runner for unit and end-to-end tests. Did anyone tried webpack:webpack with Karma? Is there a recommended testing tool? How are you testing (unit + e2e) your webpack+meteor app?
I ended up running all my tests with Chimp, end-to-end as well as “full-app unit tests” thanks to their amazing server.execute() feature. Using a single tool for all the tests is really great.
Need this too! Using flow router + webpack! Don’t know how to ssr
Hello @benoitt, would you mind making a list of the pros and cons of using webpack:webpack over modules? From my experience with rocket:module (which I’ve discontinued work on because modules meets my needs so far, although I foresee problems at the point when I’d like to use something like glslify for GLSL dependencies). One obvious advantage of using webpack:webpack over modules means I’ll be able to glslify my shader code. Would you mind sharing other pros/cons of switching to webpack:webpack from modules (or can both be used together, etc, just basically all the things to consider when migrating a whole app from modules to webpack:webpack)?
Does anyone here knows how to do a require('fs') on the server side? I keep getting an empty object as result, as written here:
This one is fixed; turned out to be a problem in the Apollo package.
Does anybody in this thread still use Meteor with Webpack? If so, how do you do it now that meteor-webpack is no longer supported? I’m not surprised, as lots of people (including myself) were bugging @benoitt about it – can’t spend that much time maintaining a side project.
That aside, what tools and project structures have you all migrated to? My project is still roughly based on the kickstart-meteor-react-router boilerplate. The underlying Meteor libraries are rapidly falling out of pace with the rest of the ecosystem, what have people migrated to?
This blog post about having entirely separate front & back-end apps is the best-looking solution I’ve seen around, but it depends on moving to a different DDP library on the client – not a great option. What are y’all (@imkost, @efrancis, @markoshust, @aislan,@zaklampert, @juliancwirko, @zafaransari, @arunoda) doing these days?
Personally, I think Meteor will be just a build system sooner or later, so this is probably a matter of choosing the build system you like (just my opinion). Even now, existing build system is enough in many cases and I guess it will be better in the future. I hope it will be a good competitor for Webpack.
Regarding the separation of front-end and backend. You can always switch to Apollo instead of DDP and use Webpack for front-end app and Meteor as a backend only. This is also an interesting solution if you really like Meteor’s backend API. Nowadays, I don’t recommend using DDP at all, but this is just me 
The build time is just killing me right now, even with the new version. Meteor methods and realtime out-of-the-box has always super useful, but managing dependent pub/subs is a mess. Apollo looks like it’s worth investing some time in! Especially if it’ll transparently sync our existing pub/sub to Redux. Is that what you’re using now?
It depends. I don’t want to use Apollo in every app. In small and even medium apps standard Meteor is still very good choice. Very fast start without configuration, good and simple deployment options etc.
But sometimes it is even simpler to just create REST backend in Node (express, hapi, whatever). You probably need to find the best tools for the job. In bigger apps Apollo and GraphQL is great imo.
Are you speaking hypothetically? Or is there a package that does that?
Don’t know many details as I found it today, but that’s what Vulcan.js says on their Using Redux page! Apparently it’s just the new version of Telescope, so there’s a whole lot of instrumentation coming together to deliver that sync.
Are you referring to this?
Redux is used transparently by Apollo to cache your data on the client
I was referring to GraphQL data fetched by Apollo, not pub/sub data. Apollo doesn’t do anything with pub/sub data or minimongo, it’s not tied in with Meteor in any way.
Ah, I gotcha. Is MDG moving all its focus to GraphQL patterns rather than the old Meteor pub/sub data layer?
I don’t want to speak for them but I get the general impression that they see pub/sub as a fairly stable and mature system that works great for what it’s supposed to do, and they now want to invest their focus in Apollp.