Can I use Ember with npm and webpack?

Hi, I try to compare several frameworks and currently struggle with Ember.

  1. Can I install Ember with npm? It looks only Bower is supported.
  2. Can I use webpack with Ember? It looks like I need to use ember-cli?

I made a little bit of progress:

// package.json (using Ember@canary, but it could be any version)
{
  "dependencies": {
    "components-ember": "https://github.com/components/ember/tarball/canary"
  }
}
// src/jquery-shim.js
import jQuery from 'jquery';
window.jQuery = jQuery;
// src/ember-shim.js
import './jquery-shim';
import 'components-ember';
export default window.Ember;
// src/app.js
import Ember from './ember-shim';
console.log(Ember);
  1. I don’t understand this question. Do you mean including libraries that only distribute on NPM? If so, there is ember-browserify addon you can use to import them.
  2. I can’t say it’s a definite no, but there is not much point of using webpack when ember-cli already does everything for you out of the box: transpile ES6 and package into AMD modules via babel, concatenate JS files together (with source map), and linting via JSHint.
  1. I want to install Ember with npm. There is no official Ember package in the npm registry (just a very old mirror) and I can’t use the official repository (because the package.json has no main). So I use "components-ember": "https://github.com/components/ember/tarball/canary".
  2. “there is not much point of using webpack” → I probably learned more about Ember with trying that than by reading the docs by now. Besides that it is good for experimentation and to use existing knowledge. “ember-cli already does everything for you out of the box:” → Who says I want to do the same with webpack :slight_smile: Anyway… I have a working example now: https://github.com/Mercateo/component-check/commit/c8b4df0b6e342e48d12fab480e1d5ca4417f9195

Ember is neat to stop using bower completely, but not yet, so its a bit more complicated. I’m glad you figured it out how to do it.

That said, if you’re trying to use ember for it’s usual purpose (build and app) I cannot encourage enough to not use webpack and use ember-cli. If you’re new to ember probably you’re not aware of to how many awesome work you’re renouncing by not using ember-cli.

To put you in perspective, it would be equivalent to say “I want to use javascript but without all those pesky arrays”. Is that awesome.

I don’t think it’s totally pointless to ask about webpack support. I like ember-cli and how it (naturally) doesn’t need any configuration at the build tool level, but I still miss webpack’s loader plugins that allow almost all css and js libraries just to be required or imported after npm install --save.

1 Like

FWIW, it might be easier to adapt something for ember-cli than the other way around.

Good job Pipo!

@lightblade, @cibernox I believe in the long run, the thinking behind “ember-cli or nothing” is very harmful to the Ember ecosystem. It leads to more and more withdrawing into itself. Openness is good. Interoperability is good. You could even argue that you can measure the usefulness of a tool by counting how many other tools it can interact or be integrated with.

Pipo’s work on building webpack integration for ember is a good thing.

By the way Pipo, would you care to summarize what you learned in the process? I am trying to get a better understanding of ember-cli, for the purpose of altering the results (I’d like to have it create a rollup bundle instead of AMD modules and suppress all the non-js tasks).

My understanding now is as follows: ember-cli consists of two main parts:

  • The ember command, which is basically a wrapper around other tools. All its commands basically build some configuration data it then feeds to either of those tools. In particular, it builds a proper tree for Broccoli. Once the tools are done, it pretty-prints the results.

  • A default project structure that glues ES6 modules together to make an Ember application:
    • It has babel output AMD modules
    • It has loader.js provide requirejs-like runtime
    • It has ember-resolver use loader.js-registered modules for lookups.
    • It has ember-load-initializers launch initializers manually, so that files living in initializers directory do not have to call addInitializer explicitly.

As a sidenote, most Broccoli plugins used by ember-cli are maintained by Ember team itself.

At this point, my thinking is using AMD modules is the core idea of ember-cli, so I’m more and more considering to using Broccoli directly.

No, it’s not pointless. There is never such thing as a pointless question :smile:

I just mention that unlike in other ecosystems where there is no “official” build tool, ember has one and a lot of open source work is designed to plug into ember-cli. Therefore your motivation to take another path should be very strong, because you’re renouncing to a lot.

About loading JS and CSS libraries installed from NPM, the thing most (all?) people use is ember-browserify.

I have to disagree strongly on this. This is precisely the main selling point of ember compared with anything else in the JS world.

Rather than just being a .js file you link in a script ember carries a whole ecosystem of tools and addons that “just work”. That level of just work is unattainable without some degree of ecosystem consistency, and ember-cli is the tool that enables it.

Without having ember-cli as the main target, addons couldn’t be nearly as powerful as they are.

You can always choose not to use it, and it’s perfectly fine, but it requires some extra effort that very rarely worth it.

Thank you all for the nice and healthy discussion! I appreciate that.

Maybe one more reason why I tried webpack: We have heterogeneous projects. ember-cli is nice if one Ember dev switches to another Ember project. With webpack and heterogeneous projects it is the other way around for us. For a JS developer coming from a non-Ember project it is easier to switch to an Ember project with webpack. I tried several very different frameworks and all use the same webpack file without modifications.

And if you want to hire a new developer which will be easier to find: a JS developer or an Ember developer?

@spectras: I’m sorry, I can’t add more to what you already said. Your comment covers even more detail I knew before.

I really like that Ember has an “official” build tool. This is really great for 90% of all projects. For the other 10% projects it would be nice to see non-ember-cli examples in parallel to ember-cli examples. I really like the approach of Angular 2 docs here: every example is written in Dart, TypeScript and JS even though TypeScript will be the “more official way” to write Angular 2 apps.

The whole Javascript community feels that ember-cli is a powerful and amazing tool. For this reason Angular asked the Ember-cli team to help them to build Angular-cli. It means other frameworks will enjoy the ember-cli’s benefits soon. :slightly_smiling:

However there was a nice experiment to squeeze Ember in webpack and if you really would like to use webpack and Ember, here is the solution: GitHub - Mercateo/component-check: A quick introduction to exploring how components can be created in several frameworks.

1 Like

Ha-ha :smiley: Thank you. This is my experiment :smile:

1 Like

@pipo Ha-ha :slight_smile: Well done mate! It is an amazing job! Keep up the great work. :slight_smile:

Hi, I used everything from this thread to create a really nice integration with webpack. I’ve created a more complete todomvc app using components, services, etc, to validate the experiment.

You can check the todomvc app:

code: GitHub - tulios/ember-webpack-example: TodoMVC app implemented using Ember + webpack

working demo: ember.js with webpack • TodoMVC

I wrote a little bit about the reasons and the process here:

Thanks @Pipo for all the information and hard work!

2 Likes

Thank you. This is a very nice article. A migration from an existing project is a valid reason to investigate into webpack. It was one of my reasons as well.