Concerns over this library

[bcardarella]

I have some serious concerns about this library, if its intention is to be the path forward and representative of what Ember will be like when it is modularized. We are discussing its use over destructuring internally at DockYard. Here is where I am currently landing:

Ember's own project organization

This library exposes an issue I have with Ember's organization. It doesn't feel intuitive and is not simple to find things. I'm sure those who work on and contribute to Ember on a regular basis will disagree but for someone who has been working with Ember for over four years and has made contributions back to core several times I can honestly say I have no idea where anything is, ever. It ends up being a guessing game every time. Up until now that has been little more than an annoyance. But if Ember's structure is going to be exposed through the module system this annoyance is significantly magnified.

Documentation

Part of the way people learn is through discovery. They see a demo and say "Ok, I need to import ember-metal/get but I'd like to learn more, let me look up the documentation" and they're treated with http://emberjs.com/api/modules/ember-metal.html which isn't very helpful.

This is even better illustrated with the modules defined in this shim that don't exist at all. ember-array or ember-object for example.

Why modules over paths?

This issue was brought up over a year ago when the module style for all the packages was originally proposed. I am still confused as to why core prefers ember-object over ember/object. I thought things landed on @stefanpenner proposing the use of @ember/object. I cannot recall which project this was discussed in, otherwise I would link to the issue.

[stefanpenner]

I thought things landed on @stefanpenner proposing the use of @ember/object.

Ya, I'm not sure why this path wasn't taken. I would still prefer it.

---

As per learning/docs. I suspect the docs will evolve once the dust settles on module signature.

The nice thing though, is any modules are better then none. And the static nature of them, means if we decide to transition to another format. An automated tool could very accurately make the transition in one swoop.

cc @locks as he may have some learnings ideas.

[bcardarella]

re: @ember/foo

is there an opportunity to change the syntax of the modules in the library? Last I recall everyone was on board with that style

[stefanpenner]

Last I recall everyone was on board with that style

Was this the case, i seem to remember push-back. I of-course am biased, and prefer the @ember/foo pattern.

Ultimately no hasty changes will be made, but the above comments are useful.

emberjs/rfcs#68 hasn't been merged, which means it hasn't been finalized. So continuing this discussion there might be appropriate. emberjs/rfcs#68

[Turbo87]

closing this as emberjs/rfcs#176 has replaced emberjs/rfcs#68 and essentially deprecated this project