Move to PODs

[bj-mcduck]

Would it be ok to move the internals over to a POD structure?

I think that's the current, or future standard... and I like it.

[miguelcobain]

It makes total sense to move this into pods.
Is it possible in addons? I guess it is, but never tried.

[hhff]

wasn't possible as of a couple months ago - addons had to follow the old structure

[hhff]

mainly because pods was opt-in in the host app.

if we introduce pods, we'll have to cut compatibility for older ember CLI versions

which I think is fine

[bj-mcduck]

@miguelcobain what were you saying earlier that we should use as a convention?
Support the current beta, and the last two stable releases of ember/ember-cli?

[hhff]

@brandonjmckay https://github.com/kategengler/ember-try

[bj-mcduck]

I actually don't know if it is possible in addons yet. But if it is, then it would be sweet.

[bj-mcduck]

@hhff Should I be looking specifically at https://github.com/kategengler/ember-try#limitations, or https://github.com/kategengler/ember-try/blob/master/bower.json#L5 for that information?

[hhff]

I doubt pods are ready for addons - just noticed the ember-cli folks are still writing an official RFC for pods.

Ember Try works for addons though! https://github.com/ef4/liquid-fire/blob/master/config/ember-try.js

[miguelcobain]

Support the current beta, and the last two stable releases of ember/ember-cli?

Yes. That's what ember-try tests against and ember-try is now an official dependency of ember-cli, so yes.

[bj-mcduck]

See: ember-cli/ember-cli#3586

This issue can be addressed when ember-cli/ember-cli#3596 is closed.

[miguelcobain]

This is now possible.
From my first stab at this, I don't know if it makes that much sense.
Many components just have a js file.
So we end up with lots of things like:

+paper-content
  |-component.js
+paper-card
  |-component.js
+paper-card-content
  |-component.js
...

Also, we have many components which are related with each other. It would make sense to have them together in a directory, like angular material does.

+paper-content
  |-paper-content.js
+paper-card
  |-paper-card.js
  |-paper-card-content.js
+paper-auto-complete
  |-paper-auto-complete.js
  |-paper-auto-complete.hbs
  |-paper-auto-complete-highlight.js
...

Thoughts?

/cc @xomaczar @knownasilya

[knownasilya]

Grouping them categorically might make more sense, and help the codebase be more self documenting maybe..

[xomaczar]

@miguelcobain the first example is supported out of the box by ember-cli resolver. Does it make sense? It does - it keeps logical parts of a component - hbs/js next to each other. Your second example might require a custom resolver, and contains unnecessary name duplication. I think @rwjblue is working on pods 2.0 maybe he can point us in the right direction?

[miguelcobain]

@xomaczar AFAIK, within the addon folder, we can do pretty much what we want, as long as we re-export components correctly in the app folder.

So, for example, this is valid:

+addon
  +components
    +paper-auto-complete
      |-paper-auto-complete.js
      |-paper-auto-complete.hbs
      |-paper-auto-complete-highlight.js
+app
  +components
    +paper-auto-complete
      |-component.js
    +paper-auto-complete-highlight
      |-component.js

Please, correct me if I'm wrong.

[xomaczar]

@miguelcobain you are right, forgot about app import - export part.

[gristel]

I'm with @knownasilya about the grouping them categorically. It may make more sense to new users and lower the ease-of-use level (if that makes sense)

[miguelcobain]

@gristel In terms of "ease-of-use"ness, users won't note any difference. They'll just use their components normally.
Internally, however, the project would be easier to understand and contribute.

[gristel]

Actually, that's what I meant :) Not people just using the components. I should have said new contributors instead.

[DanChadwick]

Since:

• pods are not the way of the future
• Module Normalization emberjs/rfcs#124 hasn't happened yet
• there isn't any upside to ember-paper users (affects contributors only)
• we have much more pressing priorities

I suggest we close this. We can also re-open if/when there is something concrete that we want to do with our directory/naming structure. Any objections?

[miguelcobain]

@DanChadwick we can close this since this topic is mentioned in #249 (i.e it won't get lost).