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

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

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

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

1 Like

You update both versions? (-:
And change, pls, git clone url (-:

Really cool stuff.

I’m a bit new to the locally imported modules though and have mixed feelings about them. I’m missing having my collection classes available in the javascript console for example.

Is there an easy way of making them globally available?

You could easily have a file that would make them globally available.

Collections = {
  TodoItems: require('TodoApp/collections/TodoItems'),
  // ...
};

I don’t think global variables are good pratices though.

I’m wondering if client/ and server/ folders can be avoided within modules. Each file is explicitly required/imported, so I’m guessing this is only for organization.

This is 100% because of Meteor and we can’t change that (at the moment). If you change a file that is not within a client folder, the server will recompile. This means the hot-reload will not work.

1 Like

It’s better to make them global only for development:

const Items = new Mongo.Collection('items');

if (Meteor.isClient && process.env.NODE_ENV !== 'production') {
  window.Items = Items;
}

export { Items };
1 Like

This makes a lot of sense, thanks for the tips!

    Installing NPM dependencies for the web bundle...
npm WARN EPEERINVALID babel-loader@5.3.2 requires a peer of webpack@* but none was installed.
npm WARN EPEERINVALID react-addons-css-transition-group@0.14.0 requires a peer of react@^0.14.0 but none was installed.
npm WARN EPEERINVALID redbox-react@1.1.1 requires a peer of react@>=0.13.2 || ^0.14.0-rc1 but none was installed.
webpack built 99f56fa3976d7b0815d3 in 3623ms \
Installing NPM dependencies for the server bundle...
npm WARN EPEERINVALID babel-loader@5.3.2 requires a peer of webpack@* but none was installed.
npm WARN EPEERINVALID react-addons-css-transition-group@0.14.0 requires a peer of react@^0.14.0 but none was installed.
npm WARN EPEERINVALID redbox-react@1.1.1 requires a peer of react@>=0.13.2 || ^0.14.0-rc1 but none was installed.

Getting this error after upgrading and following your migration steps. What did i miss?

Edit: the app is actually running fine with these errors, but when I run meteor i’m getting a packages.json parsing error (because that file is no longer in the project) and the symlinked node_modules folder shows up, even after running unlink node_modules

npm WARN means warning, not error ;). This is actually because of peerDependencies on react. We are getting React with the Meteor package instead of NPM. This means it thinks it is not installed. You can ignore those warnings. I’ll make a fix to make them disappear in the next release.

I see you’re using react-addons-css-transition-group but this package is made to work with React 0.14. Meteor hasn’t updated to 0.14 yet so you might want to keep using React.addons for now.

1 Like

Hey! Bonus help. Thanks man. That was my next thing to tackle…

I guess i’ll toss this one out too for you or anyone - should this set up work with ngrok? It’s been insanely handy for our dev stack to live test on other devices. When I start up an ngrok tunnel with the kickstart-flowrouter project, I can connect, but nothing shows up. Maybe there’s a better way to do a reverse proxy?

It will work if you set the right value to devServer.host in your webpack.conf.js. Basiclly, you need to make sure you can connect remotely to your webpack dev server. On your computer, localhost will work. You can change it by the ip / domain name so it works with ngrok. Never used it before it seems pretty cool.

Great. I just changed it from localhost to my computers local IP address and it worked perfectly. Thanks again.

Has anyone managed to get Sass working? I’m getting the following error:

ERROR in The `libsass` binding was not found in /Users/coniel/Sites/kickstart-hugeapp/.meteor/local/webpack-npm/node_modules/node-sass/vendor/darwin-x64-11/binding.node
This usually happens because your node version has changed.
Run `npm rebuild node-sass` to build the binding for your current node version.
 @ ./modules/Core/client/styles/layout.scss 4:14-187 13:2-17:4 14:20-193

After searching I found this solution, but it didn’t work for me.

I have sass working

In webpack.packages.json I added

  "node-sass" : "3.3.3",
  "sass-loader": "3.0.0",

in entry/webpack.conf.js I added to the resolve.extensions

  '.scss'

in entry/client/webpack.conf.js I added to module.exports.module.loaders

{ test: /\.scss$/, loader: 'style!css!sass' },

Yep, I have all of that as well. Apparently the issue is that Meteor is using a different version of node than my local version, which the script I linked to should somehow fix (I’ve never worked with Node directly so I don’t really know what it’s doing), but it didn’t help.

Yea binary Node.js libs are real bitches. The last Meteor version is under 0.10.40.

Here is the script I was using for node-sass:

#!/bin/bash

# If you have this error:

# Error: The libsass binding was not found in ../node_modules/node-sass/vendor/linux-x64-11/binding.node
# (STDERR) This usually happens because your node version has changed.
# (STDERR) Run npm rebuild node-sass to build the binding for your current node version.
# (STDERR) at Object.sass.getBinaryPath (../node_modules/node-sass/lib/extensions.js:150:11)

# It is because Meteor is running on a different Node.js version than your local version. You can fix it easily:

# 1. Open this script with your favorite editor
# 2. Set the correct SASS_BINARY_NAME value based on the directory between vendor and binding.node in the error message: .../vendor/linux-x64-11/binding.node
# 3. Run the script and the error should disappear

SASS_BINARY_NAME=linux-x64-11

# This should be the Meteor Node.js version (not local version)
METEOR_NODE_VERSION=v0.10.40

ROOT_FOLDER=$( cd "$( dirname "${BASH_SOURCE[0]}" )" && pwd )/..
cd $ROOT_FOLDER/.meteor/local/webpack-npm/node_modules/node-sass
export SASS_BINARY_NAME=$SASS_BINARY_NAME
node $ROOT_FOLDER/.meteor/local/webpack-npm/node_modules/node-sass/scripts/build.js --target=$METEOR_NODE_VERSION --force
2 Likes

Sweet, thanks, got it working. Not sure why it didn’t work before (I modified the original script I linked to to be basically the same as this and it didn’t help).