Future of Pods?

[mehulkar]

After Colocated Component Templates (in 3.13), the motivation to keep Pods seems pretty low. I don't see a good reason for Ember CLI to keep supporting this out of box (other than that some of those who already use it, like it)

[NullVoxPopuli]

I think we should deprecate pods. Ecosystem tooling has already implicitly made their stance as well. 🙃

[rwjblue]

Ya, seems fine to deprecate, but I personally would like to solve colocation for route templates before issuing deprecations.

[webark]

Could this be something that would be good to be tied to the embroider release?

[webark]

and coming from someone who has used pods almost exclusively since the beginning, having components be able to nested alongside routes has been helpful for me and my teams. It would be nice to maintain that functionality which was an original feature of MU.

[mehulkar]

having components be able to nested alongside routes has been helpful for me and my teams

@webark this does seem nice, we use rough namespacing where it matters for this. is the benefit to be able to route split better? or is it better for team communication? something else?

I personally would like to solve colocation for route templates before issuing deprecations.

couple things to research:

• can pods functionality be entirely moved out into a different resolver and passed into the App instance?
• is colocating route templates achievable without invoking the messy controller+query params conversation? (and if so, is it good enough to colocate templates+routes and leave controllers where they are?)

[mehulkar]

and coming from someone who has used pods almost exclusively since the beginning

how often do you run into problems or inconveniences? doesn't debugging everything become way harder?

[webark]

More just for team communication and organizational patterns. There are just some components that are only useful in certain contexts, where as others are more broadly useful.

I think making the resolver more flexible to be easily extended would be great, be this through just better documentation or more exposer and stabilization of the internal apis. (moving to a non resolver api i think is nice, but here is not the place for that convo)

I see a lot of value co locating controllers and routes, as well as route templates. route templates being colocated with only routes, but can be disorientating when looking for functionality when trying they are so closely coupled to the controllers.

[webark]

how often do you run into problems or inconveniences? doesn't debugging everything become way harder?

We've never ran into issues. Sometimes there has been issues with addons, but we just always do the app reexporting as classical to avoid any issues.

There is the odd thing where you can repurpose route templates as components.. which was used once by someone who saw it as a clever solution, but just leads to confusion.. It was an easy redactor though.

[mehulkar]

Good to know. I see questions on discourse about folks using pods and I never try to help because I never know if it could be a pod-specific issue. That might be another benefit of pushing pods resolution to user land... more easy to isolate issues?

[webark]

agree whole heartedly that it should be a user land feature.

Whenever i have looked into (and the few times i have) extending the resolver, documentation and public surface is light. Would be nice for these to be beefed up to allow for pushing more to "user land" and aid in experimentation.

[timiyay]

Our company also uses pods, and we enjoy them.

Having all related files grouped into a single folder really eases the navigational burdens of Ember projects. We've also amplified those benefits recently, customising our build to support co-located tests of all types within pod directories.

I don't see a good reason for Ember CLI to keep supporting this out of box

Migrating away from pods would be a reasonably big deal for us, quite disruptive. It would be a breaking change, no doubt about it.

So the good reasons would be:

• Ember project layout is sprawling, and confusing for newcomers,
• removing support would cause breaking changes in all pod-based projects

Would it be fair to assume that, if pods support is dropped from the core libraries, that wouldn't occur until a major version release like Ember 4.0?

[mehulkar]

Would it be fair to assume that, if pods support is dropped from the core libraries, that wouldn't occur until a major version release like Ember 4.0?

yes

[webark]

and @timiyay @mehulkar I would like to say a prerequisite would be an addon that is able to extend the existing resolver using public apis.
Without this, another burden would be placed on several companies, which would just delay upgrading and adoption.

[mehulkar]

not an addon, just ember-pod-resolver (like ember-resolver), probably

[webark]

I'd be fine with manually needing to import it and use that instead of the defaultly scaffolded one..

It would have to support pods, classical, and colocated though.. as many apps have a combination (esspesially when you bring addons into account, and how they are included).

(I'm still kind of most in favor of a "resolver less" model.. but template imports are needed for that. And having the convention helps coming into a new project and solves needless discussions)