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.
Exactly. While there are more and more hard core programmers joining us, I believe most of us (at least early adopters) came to Meteor because of the cool technology that enabled us to (rapidly) build our cool apps, and not necessarily to learn so much of technologies beforehand in order to do so. Of course, as our cool apps grow, we should dive deeper into technologies, but I’d like it to happen later than sooner, when we’ll (hopefully) have enough money to hire smarter people than us to do the “real” job (no pun intended
So just to clarify, are you saying the next version will allow us to use Meteor’s new 1.3 npm functionalities (imports/exports) as well as all the awesome webpack stuff (hot-reload, .babelrc for ES7 decorators, code splitting, etc…) together? If so,
Regarding compiler plugins, what about if we wish to do some extra handling of JavaScript files besides what (for example) the ecmascript package provides? For example, suppose we’d like to have a file called foo.blob.js that is imported as a new Blob so that we can run it in a web worker. The problem I don’t see a workaround for yet is that if foo.blob.js has ES6+ syntax and imports NPM modules, then the compiler plugin to handle it will need to handle ES6 (f.e. with Babel) instead of letting the ecmascript package do it, which means duplicated efforts.
Are there any plans yet to support multiple plugins somehow acting on a single file? This feature would be to Meteor packages as what loader chaining is to Webpack.
Note that the ecmascriptplugin is very handily designed to import everything from the babel-compiler package, so this wouldn’t be too hard to re-use in this case.
Re hot module replacement (or more specifically, react hot loading). It sounds like a proper solution in Meteor that covers all cases will take a lot of time, but for those who want something now for a subset of cases, I’m progressing nicely with a workaround until something official is available.
+1.
When Meteor first came out, it did a lot of magic. Isomorphic code was unheard of, reactivity was unheard of. Heck, they even did Mongo on client-side! But they did it. When I think about it, how hard can it be to provide an abstraction layer on top of webpack so its as simple to use as meteor add webpack. It might sound like a lot of work, but building HMR and code-splitting from scratch sounds even more difficult. Why re-invent the wheel, MDG could’ve focused on creating a native webpack package which works without tons of configuration.
Blaze was pretty tightly integrated with Meteor, or so it looked, but React came along and MDG started supporting react. So now people can slowly migrate away from blaze to react. Why not something similar for webpack? It’s hard to believe that it’s undoable.
I don’t see evidence that it supports hot reloading with ES6 syntax, but then again, what does? Eventually a standard syntax for hot reloading will come out, and if bundling isn’t an obsolete concept by that time, I’m sure Webpack will support it.
I want Meteor to be a set of npm packages too. However, in that case there would be no need for a meteor-webpack or any other hacks to integrate with Webpack anymore. Unless, I suppose, one was still using Meteor isobuild with it…but I’d rather forego isobuild entirely
This is a slippery slope that could lead to people asking for MDG to roll their own version of more and more of Webpack’s nice features.
But not only that; in the long run other shiny new bundlers like Rollup may gain prominence or even prove superior to Webpack; and then people would start bugging MDG to copy features from Rollup et al!
So I think MDG would do itself and everyone else a favor if it seeks to transform Meteor into npm packages so that people can use them with whatever bundler they want. Then MDG could abandon Isobuild entirely. They would be free from the need to keep catching up with other bundlers, and Meteor devs would be free from the need to write Isobuild adapters for various tools, since they could just use already-existing Webpack loaders or the equivalent for other bundlers like Rollup.
Having CommonJS stuff in our code isn’t really holding it back that much. People have already released scripts for jscodeshift that automatically convert require statements to import statements. Similar scripts to convert async requires to System.import calls wouldn’t be terribly difficult either.
By automatically converting these and a few other things, we would have code that runs in a browser with ES2015 support without any bundling via Webpack (all that would be needed is to organize npm packages in a format importable in the browser, via JSPM or similar). So Webpack has not trapped our code very much.
In contrast, Meteor still traps our code by requiring it to be run through meteor/isobuild. Technically, loading all the scripts from program.json and injecting __meteor_runtime_config__ manually is probably sufficient to escape that trap on the client side, but it feels like a hack, and I’m not sure what escape on the server side would entail.
I just realized, that if Babel is passed the filename of a file when compiling it and if it passes that filename to it’s plugins, then when Meteor 1.3+ starts supporting .babelrc, we can implement the “loader chaining” (as far as JavaScript files go) with Babel plugins.
