Why is the Meteor.install(1.3) api better than webpack in meteor?

[jedwards]

This is no longer true; Webpack is adapting to the evolution of JS just like anything else. See https://gist.github.com/sokra/27b24881210b56bbaff7. Webpack 2 natively supports:

• import and export
• code splitting with the System.import standard

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.

[luisherranz]

@dpacmittal

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.

I want to suggest a different approach: instead of brining Wepack/NPM to Meteor, why not bring Meteor to Webpack/NPM?

Npm install meteor (Meteor client as a NPM package)

Meteor is trying to open itself to NPM with Meteor 1.3, which is great. But somehow Meteor is always behind. Hacks are needed to work with the best tools, like the ecmascript package, the webpack:webpack project or Meteor 1.3 itself. There are a lot of bugs, delays and non-compatibilities. Why not give us the opportunity to use the Meteor client side as a set of NPM packages as well: npm install meteor-base npm install meteor-ddp npm install meteor-minimongo npm install meteor-accounts ... We…

Abstractions to simplify webpack can be built on NPM as well.

npm install simple-webpack or npm install meteor-webpack

[jedwards]

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

[jedwards]

@trusktr

This feature would be to Meteor packages as what loader chaining is to Webpack.

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.

[jedwards]

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.

[trusktr]

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.

[wecare]

what do you mean cry? easy or hard?