It can’t be deprecated because it was never supported to begin with.
Pods is a “use at your own risk” experiment that took on a life of its own and lingered way too long. People who really liked it promoted it and got lots of other people using it. But it has never been in the official documentation and it never got a consensus RFC.
There is a whole chapter about pods in Ember CLI guides. I always thought that it’s an alternative way to structure the app.
I’m fine if the Ember team decides not to use it, but I would appreciate that it would be communicated better. I found out that it’s not working when I made a minor upgrade from Ember 3.12 to 3.16 which doesn’t leave me with a good impression.
Is that because of something that changed with template co-location being added in Ember 3.13? I’d be very surprised if support for pods was simply dropped. Even the template co-location RFC mentions a pods generator still.
It did look like there were some temporary issues with pods and Octane related stuff but maybe they are resolved now?
All that to say I don’t think support for pod layout has just been dropped (especially with the number of people using it). I’d suspect if it’s not working it’s some sort of bug. Asking in Discord might be a good idea.
No. Choosing yarn over NPM is like choosing VSCode over IntelliJ. The coupling between Ember and your editor is low to nonexistent. Same goes for the package manager. Once npm install or yarn install finishes running, from that point forward they’re sufficiently indistinguishable that node and ember really don’t care.
Pods is nothing like that. It’s a significant change to ember’s internals. It’s a much higher-stakes place to go off the happy path. Nobody is actively trying to break pods, but that is hardly required. It just demonstrably gets less energy supporting it, which is why we have threads asking “why is X thing broken under pods?”.
Haha still not sure this is fair, before Ember CLI added support for yarn it did not work the same or as well as npm. There was deliberate effort that went into making yarn work well with Ember CLI apps even though it wasn’t documented.
I don’t really care either way here, I just think the confusion was all very preventable with firmer language and stronger stances around things. (And further ongoing confusion would still be ameliorated with better communication rather than silence.)
Pods feels very much like “intimate API” to me, based on how it was developed, who championed it at the beginning, its close relationship to MU, its documentation in the Ember CLI guides, and so on.
I agree with Sam, it seems very harsh to say “oh, you shouldn’t have been using Pods” all these years when it was a highly talked about thing and used by many. Same feeling as it being “intimate API”. If for whatever reason pods “breaks”, I’m sure you’ll hear from those who’ve been using pods.
Sure, that’s what this thread is. Like I said, it breaks a lot.
That does carry weight. Nobody is going out of their way to break pods, and a lot of people work hard to fix problems when they come up. But it’s just demonstrably true that extra problems do come up, and that’s unlikely to change.
Since the time when pods happened, the community has gotten a lot better at avoiding this kind of situation. Under today’s community standards, pods would definitely not have shipped. Having two competing whole-app layouts is extremely non-ember-ish, when the whole premise of the project is shared, community-supported conventions.
I will concede and take back what I said about “not supported”. That was hyperbole. Pods did manage to sneak into stable releases and it’s a bug when pods breaks. But letting it sneak in was a mistake.
Is there a way to “convert back to the regular way” (automated - I tried finding a codemod, but couldn’t).
I’m upgrading to 3.11 and was trying the angular-bracket-codemod which doesn’t work on pods.
I guess that it shouldn’t be a big problem migrating components to the “template colocation” on Ember 3.13, due to having a components folder with component name and the component.js/template.js , might break some imports eventually.
What’s the community way of migrating away from pods?
Pods still works but it was never “an official thing” IIRC and has been superseded by template co-location so I would recommend that template co-location scheme be used for any new/refactored code. It’s basically the same as pods but with different file names:
for example, for a component like <SomeParent::SomeComponent />
app/components/some-parent/some-component/index.js
app/components/some-parent/some-component/index.hbs
// or
app/components/some-parent/some-component.js
app/components/some-parent/some-component.hbs
EDIT: and FWIW the two are compatible, we have pods and co-located components and we also have some even older “classic” components as well. All work well interchangeably while we migrate fully to co-located.
EDIT 2: i don’t think co-location yet works for route/controller/template so that’s something to consider
