the rest is basically depending on what version of Ember I use so it could be specified somewhere else. It would be great to have something similar to create-react-app so I can upgrade just one package and get all the awesomeness included.
@rwjblue are you saying those deps are all required to run an ember app? If so, shouldnt they be specified as dependencies in the ember-source package? So the consumer doesnt have to have them specified?
Humm… is there a table showing compatibility between versions? Personally I stay in lock-step, but if someone wanted to go off track, how far can they go off track?? Might be worth a page somewhere on emberjs.com, or at least list compatible versions in the release notes.
ember new app-name --skip-npm
cd app-name
npm install --production
and you should end up with a project containing only the essential dependencies to run the app, aka npm will not install modules listed in devDependencies as described here but I have to say I did not try this.
If you find a practical answer to this question please, let us know about it, because I am asking myself the same question every time I start working with ember.
I’m open to the feedback that having a long list of dependencies with non-obvious functionality is off-putting. But I want to caution that there are downsides to pruning this list that we should be cognizant of.
We could move many of these dependencies out of the default app blueprint and to be transitive dependencies of ember-cli or ember-source. But the biggest benefit of making them app dependencies is that it’s very clear how to turn them off: just delete them from your package.json.
Let’s take ember-cli-sri as an example. If we want to turn off subresource integrity hashes for whatever reason, today it’s as simple as deleting the package.json entry. If we made it a dependency of ember-source, we’d need to implement, test and document a configuration option for turning it off. It would be yet another example people could use to show that Ember “goes against the grain” of the Node ecosystem. And even if you disabled it via configuration, it would still be adding overhead forever: in your node_modules directory, downloaded every time you yarn install, etc.
The same goes for ember-cli-qunit. 90% of apps will use this, but for the 10% of people who’d rather use Mocha, do we want to hardcode a dependency on QUnit that they have to pay a cost for?
Ultimately, I think this is one of the tradeoffs of Node’s “small modules” philosophy. Personally, I’d rather have the control over what gets included in my app, even at the cost of a longer dependency list; at least I control my own destiny. Just look at the create-react-app dependency list, which is huge. What happens if I don’t want Jest or GraphQL in my app? I’m out of luck.
@tomdale
I agree with that and I dont care if the list is long if I understand what every dependency is for. Does anywhere exist an explanation of what’s the functionality inherited from every dependency, so that programmers are actually able to choose as you described in your answer? Because the question here is not “why the list is long” but “why I need all these things here”. Personally I would like to feel that I still have the control over my code.
I have to say, I started questioning that list, not because of the list itself, but because of the size of node_modules directory. Digging a little inside the directory stucture I understood that every dependency is replicated many times inside that folder, but I believe, correct me if I’m wrong, that this is not due to ember.
Yeah, that is the fundamental brokenness of how NPM does things.
Many of those packages have good descriptions that answer the question:
> console.log(Object.keys(require('./package.json').devDependencies).map(pkg => { let { name, description } = require(`${pkg}/package.json`); return `${name}: ${description}`}).join("\n"))
broccoli-asset-rev: broccoli asset revisions (fingerprint)
ember-ajax: Service for making AJAX requests in Ember 1.13+ applications.
ember-cli: Command line tool for developing ambitious ember.js apps
ember-cli-app-version: Adds App version number to Ember Inspector Info Tab
ember-cli-babel: Ember CLI addon for Babel
ember-cli-dependency-checker: Ember CLI addon for detecting missing npm and bower dependencies before executing ember commands
ember-cli-eslint: Ember-cli eslint support, for checking your application matches your coding standards.
ember-cli-htmlbars: A library for adding htmlbars to ember CLI
ember-cli-htmlbars-inline-precompile: Precompile inline HTMLBars templates via ES6 tagged template strings
ember-cli-inject-live-reload: Plugin for ember-cli that injects live-reload script into HTML content.
ember-cli-qunit: QUnit testing package for ember-cli applications
ember-cli-shims: The default blueprint for ember-cli addons.
ember-cli-sri: SRI generation for Ember CLI
ember-cli-uglify: JavaScript minification for Ember-CLI
ember-data: A data layer for your Ember applications.
ember-export-application-global: Sets `window.MyAppName` up as the application instance upon boot.
ember-load-initializers: A tiny add-on to autoload your initializer files in ember-cli.
ember-maybe-import-regenerator: The default blueprint for ember-cli addons.
ember-resolver: The default modules based resolver for Ember CLI.
ember-source: A JavaScript framework for creating ambitious web applications
ember-welcome-page: Welcome page for Ember CLI applications
eslint-plugin-ember: Eslint plugin for Ember.js apps
loader.js: loader.js =========
A couple of those missing descriptions are clearly documentation gaps we should fill. Even those ones have good READMEs.
But overall, they are nearly all things that you can legitimately choose not to include or replace with a more specialized choice. About the only ones I would question are ember-cli-htmlbars and ember-load-initializers (which arguably could become dependencies of ember-source, and are separate more for historical than current reasons).
It would be nice to have a doc’s page with a little more detailed description for every dependency, maybe under Guides → Addons and Dependencies section, just to stop the panic!
The issue with these kinds of things is that it is really really easy to get out of sync. If we did something like this it would need to be automated in some way…
Really? So the standard way to understand which functions are included in my app by default is really to check them one by one? The other way, of course, is trust the system.
It is just to say that this discussion was started, not by me, because of a lack of (easy browsable) information and there are more than 2 users out there with this question. I agree that perfection does not exist, but I think that the answer to the question “why is this dependency here?” cannot be just “find it out yourself”
Adding a page to the guides for “default dependencies” still doesn’t solve the “go figure it out” problem (since we cannot have inline comments in JSON that point you to the guides).
I think most folks don’t care, what they want is a working system. For folks that do care, looking at the README’s of the packages seems perfectly reasonable and is a skill that will be useful far beyond the Ember ecosystem…
I got your point. I would agree 100% only if the dependencies list was none of my business.
Since this is true, I have to be instructed about how to do that. I searched on internet any kind of information about these app dependencies last year and at the end I gave up. I did not think about opening the README files, that makes me a bad programmer maybe, but the place from where I started the search was the ember documentation.
If most folks don’t care there the whole idea of “let the user manage it” it’s pointless. And still, if this list is there for the few who cares, those few should find instructions in the same place where all other informations are collected and easy browsable: the ember docs.
This is just my idea, of course we don’t all agree and we don’t even have to. The important thing is that now, at least for the ones who followed this discussion, the situation is clear.
This makes me sad. I took it as “it’s just you” and “not a big deal to us”, while I’m sure that all folks new to ember would have the same question. It just highlights ember’s issue with (some) documentation for on-boarding new people (who might be new to node too).
How would it not? I think what @ef4 posted would be enough, maybe with links to the README for more info. It would at least get you off the ground with what’s what, with a nice path for more details. Expecting people to know that the following gives you this information is a bit much.
This is not how I intended it, though I realize that doesn’t matter much.
Because unless you happened to be reading through the guides, you would still have nothing pointing you at the documentation.
As I mentioned above this seems totally fine, as long as we can ensure that the guides page is generated automatically (so that it does not get out of sync).
The same thing can be said for all other topics i guess? I don’t need to be “pointed at” the documentation, of course when I dont know something i search it there, or google it. But again, that’s just me.
To keep the sync is as simple as updating the doc everytime the dep list is updated. I think that the automation could be a good idea, just maybe a little too complex for such an issue.
