-
Notifications
You must be signed in to change notification settings - Fork 75
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Side effects? #1
Comments
Oh, you mean using browserify and webpack together with a Meteor project? I'm not sure exactly what kind of side effects you were imagining. I haven't run into any major snags yet... I've used your babel package for Meteor by the way, thanks a bunch! |
I mean is possible to expose the packages present in Thanks to you to try |
Possibly, though I assume you would have to put whatever you want from those packages in global variables so that Meteor code could access them. Also, right now the webpack bundle loads after everything else, but you would have to make some bundles/chunks load before Meteor code that tries to use them. But rather than exposing anything bundled by Webpack to other code in the Meteor folder, I'd rather just experiment with writing all of the server code to be bundled with webpack. |
Yea that would be interesting if you could write the server code in the 'webpack' directory and copy it over. What if you had a tree like this?
Also worth mentioning, in 1.2 there're going to release a package that will just export a static html file with no blaze... that might be helpful for this repo? |
Yeah, I'd like to incorporate that package in this too eventually. I haven't had the need to try out SSR yet either, though that's a whole beast unto itself...I've seen some rather complicated isomorphic React/Webpack configs. |
Yeah agreed. However it seems like it's not too bad with FlowRouter and Meteor's
However i'm using flux now so it's going to be an additional challenge to hydrate the stores on the client. @arunoda is working on SSR for React as we speak! 😄 |
@AdamBrodzinski I'm not sure your snippet is a good idea probably would be better a solution like:
and in a separate file in
|
@grigio yea you may be correct... I haven't had a chance to play around with the SSR examples yet. having if/else seems less than ideal. @jedwards1211 I'm just kicking around ideas but would this directory structure work if you could also copy server code as well (no SSR)? This kind of hides the At any rate i'm looking forward to setting it up on a pet project this weekend!
|
@AdamBrodzinski I had actually experimented with a directory structure like that before (where you run meteor out of the root folder) but I found it kind of annoying because unless I hid the source folders for the webpack bundle, Meteor would automatically try to pull in that code (and hiding the source folders works but I just preferred to keep things visible by default). I thought new meteor projects have the .meteor folder hidden anyway so scripts in it don't get pulled in by meteor leading to a hard-drive exploding self-referential loop :) |
If I have time in the next few weeks I'll move the server code into a Webpack bundle. And If I could actually manage to set up SSR, it would be really cool. |
Hmmm. I started testing out building the server code with Webpack, as well as having a However, having 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? |
Oh interesting... Is it possible to have an ignored file for hot code reload? I can't find anything in the docs yet but if we can, then placing all the collections in an ignored 'collections' file could work. The collection reload the only part of Meteor that I can think of that can't be reloaded (it's the foo/insert is already defined error?). |
Does consider this "issue" resolved? |
I don't really see any side effects, just a few blockers. These are being gathered up in #8 in the checklist. I think this is resolved. |
Maybe an OT here, @AdamBrodzinski did you try to load https://github.com/AdamBrodzinski/meteor-flux-helpers as an npm package (for Meteor) instead of Meteor package ? If if works, newer Meteor packages can already be npm packages, just with |
@grigio Ha! I was just thinking about the exact thing yesterday 😆 react-parts also does the same thing. Going to add that later today/this week. I'm also going to publish all of my own Meteor packages there with the meteor tag. Speaking of... would Also side issue... in the hypothetical world that this would actually happen, how would we go about solving the minimum Meteor version and Meteor deps ('check', 'tracker', etc..)? I supposed since the entire build tool is built using NPM/CommonJS it wouldn't be that hard for them to convert to NPM modules? example: Bonus points... using NPM modules you can share code via modules privately with your team using NPM's private service! |
Why not An hacky way could be to throw errors or check the Meteor version at runtime..
Probably they don't want to indroduce breaking changes before the Galaxy launch :P I think Meteor 1.2 will include the cool stuff via |
Ah, Yea throwing errors would be the best solution for now I think. I hope the resolve the hacky browserify in 1.2... it's kind of weird right now. I agree with the wrapper packages.... nothing worse than 10 versions of Moment.js with varying versions. Do you know how the new NPM 3.0 is going to work? I just started looking into it and it seems they're making browsers a first class citizen. |
@AdamBrodzinski huh, I haven't even heard about NPM 3.0 yet. Sounds interesting! Although I'm wondering what more needs to be done...Webpack seems ideal already! I was just playing around with Webpack optimize plugins, and I'm guessing that will remain cutting edge even after browsers have native support for ES6 import, because not only can you reduce the number of separate bundles the browser has to request; it can also aggressively merge chunks, which I think means eliminating the overhead of using |
I'll go ahead and close this but feel free to continue this discussion |
Yea NPM 3 looks pretty cool! Checkout this:
This sounds like it would be ideal for front-end because you don't want 5 copies of Bootstrap or MomentJS. I think you're right, even after ES6 modules are native you'll still need a loader and webpack. |
Yes, and this is another reason why meteor package system exists. |
Nice, are there side effects with this approch with meteor, react, browserify on client or server side?
Is possible to load both servers with a single command?
The text was updated successfully, but these errors were encountered: