Webpack compiler inside Meteor (ES6 modules, hot reload and code splitting!)

announce
104

Do I need to install anything? It’s still not working for me. The console says “Client modified - refreshing” but the client stays the same =/

105

That should fix it… basically if you could symlink or copy that startup.js file into the ‘meteor’ folder, that would startup at the normal time. Putting it in a lib folder would prob. be best.

106

Awrrr, I’ll try new things. It should work. CLI webpack watch is working fine with Windows :confused:.

The compiler will take care of it. No need to copy anything, it’s the beaty of plugging it directly with Meteor isobuild.

What if every startup.js files were processed by Meteor like a regular JavaScript file. Would it be problematic? The term feels generic to me.

107

I know how frustrating it is for you =/

Thanks

108

Due to popular demand by @SkinnyGeek1010 @mquandalle @garrilla @none

Here is the kickstart-flowrouter project :smile:

Thanks to @arunoda for the FlowRouter. I would love your opinion on this!

6 Likes
109

Thankyou @benoitt
it’s much appreciated

110

Maybe a dumb question:
Would it work with Blaze (without react) ?

111

Sure, I don’t see why it shouldn’t work. You can remove the ReactRouterSSR, react… packages and just enjoy module import/exports.

But you won’t get improved reload times and most of the blaze extensions/libraries are available through the Meteor package system - These packages still exposes globals but can be used with “fake packages” (externals in webpack config)

1 Like
112

Yes it is possible. I think someone wrote something to use webpack hot module replacement with Blaze. Here is an example of Webpack with Blaze. You probably could adapt it to webpack:webpack.

2 Likes
113

MAJOR UPDATE
I’ve made a major fix for building in production. It was taking forever and I couldn’t figure out why. Turns out private/webpack.stats.json was responsible for that. It was triggering a new build over and over. You can now access the global variable WebpackStats instead of reading the private file webpack.conf.js.

If you tried it in production mode before, you will see a huge improvement :smile:

5 Likes
115

Coool! I have to try this! (-:

116

Is it correct to say that modules is the equivalent of Meteor packages? So, for example, instead of adding a thereactivestack:todoapp you develop a module under ./modules: https://github.com/thereactivestack/kickstart-hugeapp/tree/master/modules/TodoApp.

And then the equivalent of doing meteor add thereactivestack:todoapp is doing import TodoApp from './TodoApp', right?

117

Also wondering how could it handle requires per module? For example, a certain module might require a Meteor or npm package, but avoid including the module dependencies, unless the module is imported somewhere in the app.

118

How do you debug server side code?
I tried:

  • meteor debug / node-inspector
  • WebStorm debugging

However, nothing works. Probably, I am donig something wrong. Could you tell me if server side debugging works for you? If so, could describe shortly steps that you take?

Thanks :wink:

119

if I add a react atmosphere package e.g. izzilab:material-ui
How do I import the react components?

120

Why would you want to do that instead of using the npm package?

121

I haven’t tried node-inspector yet but I suppose it is possible. It is on my todo list but I can’t help at the moment.

Exactly the same way you would with a regular Meteor project. YOu have access to global variables the package create. You can do like in their example:

const {
    AppCanvas,
    AppBar,
    Styles,
    RaisedButton,
    DatePicker
    } = MUI;
123

The normal node inspector worked well for me the last time I tried it with jedwards webpack. The one built into meteor also worked (I think) but I remember the devtools being really old. I tend to use console.log on the server quite a bit unless it’s really hairy lol.

Speaking of serverside debugging you may want to checkout jedwards’ serverside sourcemaps if you havene’t added those… I guess they were a real pain. Not sure what the workaround was though.

1 Like
124

MAJOR UPDATE
Version 0.2.0 is released! This means:

  • No more NODE_ENV=production, it just knows if Meteor is in production mode or not
  • NPM dependencies are not anymore managed by meteorhacks:npm. The reason behind it is we don’t want to send the NPM packages to the server. We only need them while bundling. If you need a NPM package to run on the server (like PhantomJS), you use meteorhacks:npm and Meteor.npmRequire.
  • Otherwise their is webpack.packages.json. You can have multiple files in your project and it will merge them together.

Here’s the migration guide if you came from 0.1.X:

  1. Remove node_modules symbolic link in your project root folder.
  2. Remove everything you don’t need on the server from packages.json (most stuff) and add them to webpack.packages.json (you can use ^, ~ prefixes like with real NPM)
  3. Remove npm-container folder and package from your project (and also remove meteorhacks:npm if you don’t need it anymore)
  4. Build your project again and enjjoy :smile:
2 Likes
125

This is great! NPM packages installation is way more quick now.

1 Like