Copy Server Files Over

[AdamBrodzinski]

I'm creating a new issue to break it off of #1

mmm. I started testing out building the server code with Webpack, as well as having a both folder where things like collection declarations go.

However, having new Meteor.Collection(...) in a Webpack bundle doesn't work with hot reloading, because when it runs the new module, creating the collection again with the same name errors out. This isn't a problem with Meteor of course because it refreshes the entire page.

If there's any way you could share your config today for the entry point that would be great! At any rate i'm going to grind away at this today to get it to work!

If there isn't a way to have hot-loader ignore a 'collections' folder, we could define the collections in the meteor folder. This is not ideal but is better than nothing.

Another idea is to define them in a folder that webpack ignores and then manually cp them over on startup since they don't change much.

So this kind of seems like a snag. Also as far as debugging server code goes, I don't know if there's any way for Node to process the source map generated by Webpack. Maybe we should check out joe's new ES6 module plugin for the server side?

Not sure about this one. I've only used the --debug flag to invoke Node debugger in the chrome console with es5. @trusktr any ideas on this?

[jedwards1211]

Actually it's not a huge deal about the Meteor Collections. When you see that exception in the console you can just refresh the page. I'll see about updating this project setup later today

[AdamBrodzinski]

Awesome. I'm creating a new project today so i'm eager to see how to do it. I was confused on how to have multiple output points. Reading the webpack docs cover to cover at the moment.

I really appreciate all the work you put into this! 🍻

[jedwards1211]

Oh, haha, interestingly enough I just ran two separate instances of webpack, since I haven't experimented with multiple entry points either.

[jedwards1211]

Okay, I just pushed a new version that runs all of the server code via webpack as well! And I incorporated the --production flag. Let me know how it goes!

[AdamBrodzinski]

Oh, haha, interestingly enough I just ran two separate instances of webpack, since I haven't experimented with multiple entry points either.

Haha, that's one way to skin a cat! Cool! I was able to get separate files to come out but they were in the same root folder and both were sent to the client 😦 I think this might be solved with a plugin but running two webpack servers will be best for now I think.

[AdamBrodzinski]

Mother of God...... This is everyone i've ever wanted and more....

Too bad most of the Meteor community (at least on the forums) is so dogmatic 😦

[grigio]

@jedwards1211 Very nice webpack server part, will https://github.com/petehunt/webpack-require avoid 2 webpack servers?

[jedwards1211]

@grigio I don't know, that's very interesting. Technically I wasn't running two instances of webpack, but rather, one instance of webpack (for the server) and one instance of webpack-dev-server (for the client). The thing I don't know is if I also served up the server bundle via webpack-dev-server, if it would even be possible to get that bundle into the Meteor server, because as far as I understand webpack-dev-server serves everything from memory.

There's an interesting thread about this here: webpack/webpack-dev-server#62

[jedwards1211]

@AdamBrodzinski hahaha, yeah, I like this setup a lot. Now the only thing lacking in my mind is source maps in node for the server bundle. But that may be possible too: https://github.com/evanw/node-source-map-support. I'll open another issue about trying to figure out server-side source maps someday

[trusktr]

@AdamBrodzinski Sorry for the really late reply! Things have changed recently. I'm using Meteor 1.3 modules now. So far it has served my needs that I haven't been desprate enough to try webpack:webpack (I deprecated rocket:module in favor of modules).

[AdamBrodzinski]

@trusktr no worries! Yeah I think moving forward 1.3 and maybe the hotloading (via babel) would be the best bet. Modules was my number one priority. I'm still using this package in a prod app though... works great! (though I don't feel the itch to keep it up to date/synced... my setup hasn't changed much lol).