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

[juliancwirko]

There should be a found from MDG for such people like @benoitt

[harisvsulaiman]

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

[SkinnyGeek1010]

What if we made webpack so easy to use with Meteor it would be stupid not to use it?

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.

[trusktr]

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.

[benjamn]

@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.

[benjamn]

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 (require and module) that will and should cease to exist in a fully ES2015 world of import and export, 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 (import and export), 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 import and export syntax, 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!

[bysabi]

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…

[trusktr]

I replied in that GitHub issue, take a look there for a possible workaround.

[casperandersen]

Cross-posting from here:

Is Meteor Dying? State of the Meteor Ecosystem

@benjamn what are the alternatives to require.ensure and module.hot in a fully ES2015 world of import and export that will allow the same features for which we love webpack for our build system. If ES2015 or other tech is not providing an alternative, then we still need webpack and commonjs require.ensure and module.hot to do its thing. When the ES2015 world of import and export provide such capability then an alternative to webpack exists and its 3rd party loaders will need migration too. …

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.

[sacha]

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.

[aadams]

Apple has App Thinning, I like associative code with tags within the On-Demand Resources heading.

[miro]

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

[luisherranz]

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.

Uhm… I love that idea. Is that what meteor-webpack 1.0 is all about?

[benoitt]

Yup, it’s coming ver soon

[etmarch]

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,

[tonyx]

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.

It’s not just most meteor users, I would say that’s most users of technology in general.

[philippspo]

What does code splitting or hot module reloading look like in terms of ES2015 import and export? That’s a really interesting question, and unfortunately Webpack doesn’t have a long-term answer.

I guess webpack 2 now has an answer to this

[trusktr]

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.

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.

[gadicc]

@trusktr

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.

Note that the ecmascript plugin 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.

Loader chaining would be great though

[gadicc]

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.

React Hotloading in native Meteor is ready (i.e. no webpack)

Edit your react components and see changes instantly, while maintaining state. [image] Note: the implementation is hacky by design. The idea is to bring react hot loading to Meteor today, and give us / MDG more time to work out the best way to do this in the long term (see e.g. this post). Project home: https://github.com/gadicc/meteor-react-hotloader (see README for installation instructions).