A bit off topic, but 2 questions:
I really like the cross-package imports Meteor has for css preprocessors like less and sass. Is there something similar for webpack?
Is there some kind of migration guide on how to transform existing meteor apps to webpack? I can’t live with Meteor rebuild times anymore…
@benoitt et al., Webpack sounds interesting. I have a situation in which I would like to push down to the client only the (template/view/code) it needs, as it needs it.
For example, say they’re going through a wizard. I know there are 10 screens associated with this wizard. As the client starts the wizard, I push to the client the first 2 or so screens, and as they progress I send them more.
I’d like to make the connections between (templates/code) with tags if possible.
Having the capability for the client to request On Demand Resources is great. But I’d also like to use this to restrict what the client as access to. For example if a client has not purchased a feature, and it’s not enabled and they don’t see or have access to the screens, why should they actually get the screen pushed down to the client? The client should only get what it needs. Right now, it’s complicated to restrict screens, and through packaging I don’t think it can be dynamic. For example, what if the client actually pays for this added feature, dynamically sending the client the feature screens because they’ve paid would be amazing.
Maybe something analogous to Apple’s App Thinning (On-Demand Resources)?
Is this something Webpack will allow me to do?
This is exactly the reason we need this, perfectly summarized by the author of the Webpack integration module! If we can get the Meteor build system to have hot-reloading and be comparably-fast as Webpack, then I think we’ll be onto a winner.
Yes, you can do modular code loading with Webpack.
Within Meteor? How? Is there a How-to guid on this?
If this turns out to be the case, then yes, please MDG standardize around Webpack!
Video: Using Webpack with Meteor
Meteor + Webpack from the Ground Up
Meteor + Webpack + React Router: A Basic Template with Code Splitting
Yes you can do code splitting with Webpack. Essentially, the client only load the javascript of the section when he access it.
You can check the kickstart-hugeapp example where there is an admin page that will not be loaded to the client unless you access /admin.
I took the time to look on how we can implement Hot Module Replacement within the Meteor build and my head is hurting 
. I don’t think Meteor will ever see fast hot-reload without using webpack.
What if we made webpack so easy to use with Meteor it would be stupid not to use it? What if all you needed was to add a few packages and not even a simple configuration file to write? As an example, if you want to use JSX, you just add the webpack:jsx-loader package. You want TypeScript? You add webpack:ts-loader. The configuration will write itself.
It might give enough flexibility to 95% of the projects and those that really need to configure the webpack.conf.js file, they still can do it.
You bought me, when can I start using it? 
Making configuration easier might be the best option available going forward.
And to get started the sketlon app for the webpack:webpack package is enough…
If you want more controll you gotta learn stuff
Have you looked into hjs? Perhaps we could make something that sets up defaults like this, allows you to override settings, and only burdens you with:
// from hjs
var getConfig = require('hjs-webpack')
module.exports = getConfig({
// entry point for the app
in: 'src/app.js',
// Name or full path of output directory
// commonly named `www` or `public`. This
// is where your fully static site should
// end up for simple deployment.
out: 'public',
// This will destroy and re-create your
// `out` folder before building so you always
// get a fresh folder. Usually you want this
// but since it's destructive we make it
// false by default
clearBeforeBuild: true
})
To be honest i haven’t checked out your work lately as i’ve been swamped and am already using a gnarly webpack config for my current apps. The last time I checked you’re on the right track to reduce a lot of the boilerplate needed.
Hey guys, I wrote rocket:module. I think the direction that Meteor 1.3 is going in is awesome.
Out-of-the-box might the new modules package might not include all the features we have in Webpack (such as loading image files, loading SVG files, etc), but, the cool thing about modules is that we can still write standard Meteor build plugins and publish them on Atmosphere. Those build plugins can take the place of what we know as “loaders” in Webpack. For example, we can write plugins to transform images, SVG files, etc, into JavaScript CommonJS modules, which we can then import into your project thanks to the moduels package, so we’ll be able to do things like meteor installsomebody:png-modules` and then write
import image from './path/to/image.png' // is actually importing `./path/to/image.png.js`, which was compiled by a build plugin
document.querySelector('img').src = image.url // `image.url` might be a `data:` URL, or a Blob URL, for example.
The build plugin would rename image.png file to image.png.js behind the scenes (it doesn’t actually rename your original source files).
I feel this will be a great alternative to Webpack. It’ll just be a matter of time before relevant build plugins are created by the community in order to compete with all the loaders that Webpack has (or transforms that Browserify has, etc). I think @benjamn’s implementation is a good direction to go in.
@joe this will be totally possible via compiler plugins in Meteor 1.3: all you have to do is write a plugin that handles .png files and calls inputFile.addJavaScript at some point. Then, importing or requiring ./path/to/image.png will simply evaluate that javascript as a module, with whatever exports and side effects you like.
The best part is that the compiler plugin gets to decide how the image gets turned into a JS module, not the code that imports the image. Webpack’s module identifier string extensions (where the importing code picks a loader by adding extra syntax to the identifier string) get that relationship backwards, in my opinion.
Cross-posting from here:
Another serious problem with Webpack is that it assumes we’re going to be using CommonJS forever. Two of Webpack’s shiniest features, code splitting (
require.ensure) and hot module reloading (module.hot) depend on CommonJS-isms (requireandmodule) that will and should cease to exist in a fully ES2015 world ofimportandexport, and Webpack has no plan to adapt those techniques to work with a purely native module system.
The more popular Webpack gets, the more it contributes to the entrenchment of CommonJS. Webpack is very much a tool for today, when what we really need is a tool that embraces the future of the language. I gave a talk recently about why it’s so important that we move on from CommonJS to a truly native module system (
importandexport), in case you’re not yet sold on that vision of the future.
By the same logic, adopting Webpack as a core concept in Meteor would hold the platform back in the long term—and probably in the short term, too, if you read that post of mine.
When Meteor finds a way to support code splitting and hot module reloading, those features will be designed to work with
importandexportsyntax, without any dependencies on CommonJS. Unfortunately, Webpack has no insight to contribute to that still-open design problem. If you have ideas, we’d love to hear them!
Hi @benjamn I was trying to port a project to 1.3 beta but stuck with this issue: https://github.com/meteor/meteor/issues/5870
Do you have any workaround for this before next beta release?
I was trying many things without luck…
I replied in that GitHub issue, take a look there for a possible workaround.
Cross-posting from here:
I genuinely look forward to see how using ES2015+ imports and exports meets the goals. Recognises webpacks importance and eases its integration until a viable alternative that’s supported by the wider community, not just meteor. Provides for one central place to configure the entire build system with full transparency. Makes it possible to opt-out of costly backwards compatibility.
@benjamn Carry on, I love your involvement and the direction you are taking to lead meteor into the node npm eco system and the ES2015+ modules and standardisation. Thanks. merry Xmas.
Just wanted to say I tried out @benoitt’s Webpack boilerplate, and hot module reloading is pretty amazing. It’s really hard to go back to a regular Meteor app (and waiting ~5-10 seconds in between every code change) once you get used to it.
Same thing with code splitting, it’s a really cool feature. To be honest it’s something I thought would come to Meteor much sooner, because it’s pretty much impossible to build large performant apps without it.
Personally, my ideal solution would be some kind of Meteor wrapper of Webpack (or similar) that configures sensible defaults for you. Basically what @benoitt did in his boilerplate, but transparent to the end user.
And at the end of the day, I think most Meteor users don’t care that much about the technologies, and care a lot more about the features they enable. So that’s why Webpack is so attractive right now, no matter how it’s implemented behind the scenes.