Explore "official" pod deprecation

[MelSumner]

I thought it was widely known and accepted to not use pods for new apps, and it came to my attention that we haven't officially deprecated them because we never officially supported them. So I think we should explore an RFC that makes it clear that we don't support them for new apps going forward.

Some considerations:

1. would need to remove the existing generators
2. would need to remove the flag
3. would need to identify what gaps exist for folks who currently use pods (could they move away from them, what would need to be replaced, etc.
4. would need to remove references in the docs

[NullVoxPopuli]

The best use of pods I've seen is a secret, of sorts:

app/
  routes/
    {route-name}/
      route.ts # (if needed)
      controller.ts # (if needed)
      template.hbs

and then everything else is in the "default locations".
It's quite nice.
Especially, as an app grows beyond 5 routes, the separation-by-type gets really annoying.
In fact! 🥳 I was so annoyed by separation-by-type stuff back in my Rails days, I did a module unification inspired layout for Rails projects: https://github.com/NullVoxPopuli/drawers#the-new-structure

[SergeAstapov]

Agree, with 20-30 routes app the separation-by-type is much harder to follow today.

with controllers going away (are we talking this again? 🙈), this might not be a problem though

[NullVoxPopuli]

this might not be a problem though

that'd be cool, if routes were Components called by the framework (or whatever they end up being), we could essentially collapse everything down to one file:

app/
  routes/
    route-name/
      index.gjs
      footer.gjs
      nav.gjs

// app/routes/route-name/index.gjs
// disclaimer: this is made up and just an idea
import { Footer } from './footer';
import { Nav } from './nav';
import LoadingSkeletonNotSpinnersPls from 'better-loading-tm';

export default class RouteName extends Component {
  @service router;
  @use data = RemoteData(() => `https://api.whatever.tld/${this.router.currentURL}`);

  <template>
    {{#if this.data.isPending}} 
       <LoadingSkeletonNotSpinnersPls />
    {{else if this.data.isError}}
      Oh no!
    {{else}}
      <Nav @links={{this.data.value}} />

      {{outlet}}
    {{/if}}
    
    <Footer />
  </template>
}

This effectively resurrects module unification, but with none of the magic or ecosystem-wide need to support module unification, and is def more T H E P L A T F O R M

[jrjohnson]

This would be a helpful signal from the framework. As an addon maintainer I sometimes (not nearly as much for the last year) get a bug report for pods that I usually feel uncomfortable closing. Often it gets a "We're happy to take contributions" response. Officially saying pods doesn't work would be a nice thing.

[runspired]

Literally every app I've ever contributed to uses pods in some capacity, usually for routes+controller+route-templates while leaving everything else in the classic structure. Given this ability is 100% built on a public API (the resolver) until the resolver itself is not a public API I don't see a reason to remove the limited blueprint scaffolding there is (which is what this issue proposes doing).

A side note: tools that have chosen not to support pods have actually done themselves a disservice imo. For 99% of things it is just a matter of supporting globing for files instead of expecting a flat structure: an approach that is far more embroider-proof than assuming the classic file structure with certainty. In nearly a decade of using pods now, I've yet to hit a point I regretted using pods.

[barryofguilder]

The best use of pods I've seen is a secret, of sorts:

app/
  routes/
    {route-name}/
      route.ts # (if needed)
      controller.ts # (if needed)
      template.hbs

I would be really upset if I was no longer allowed to use "pods" for routes/controllers/templates. This has been a huge win for all the large Ember apps I've worked on. I also think it helps with my mental model. When I need to do something for /login, I want to go a directory called login and see my route.js, controller.js, and template.hbs files. I don't want to have to expand 3 different folders and find each file in the large list.

[runspired]

The best use of pods I've seen is a secret, of sorts:

It's not really a secret, I feel most apps of any size realized this structure and moved to it 😅. I've got a codemod that will even convert you to it :D

[ijlee2]

When hearing others' perspectives on pods, I think it's good to consider where a person is coming from.

For me, we at work have a small team (the deciding factor), so I'm much for following the conventions in Ember. This saves us time from developing around an alternative approach (e.g. pods, private methods in ember-source, third-party addons) and maintaining the resulting solution, which is often not documented and tested thoroughly.

The Ember community, similarly to at my workplace, is a small team. We have limited resources to develop and maintain Ember projects, and I'd like to see us dedicate these resources to projects like Embroider at the moment. I find that it's unreasonable to ask addon and tooling authors to spend their time to support pods (for us, who decided not to follow the conventions in Ember) and increase code complexity and maintenance cost.

In addition to a few codemods, even ember-data doesn't support pods well, because it causes ember-cli to generate test files incorrectly. If we set usePods to true, the test for every adapter, model, and serializer will get the same file name.

/* .ember-cli */
{
  "disableAnalytics": false,
  "isTypeScriptProject": false,
  "usePods": true
}

❯ ember g adapter product
installing adapter
  create app/product/adapter.js
installing adapter-test
  create tests/unit/adapters/adapter-test.js  ⬅ should be `tests/unit/product/adapter-test.js`

❯ ember g model product
installing model
  create app/product/model.js
installing model-test
  create tests/unit/models/model-test.js  ⬅ should be `tests/unit/product/model-test.js`

❯ ember g serializer product
installing serializer
  create app/product/serializer.js
installing serializer-test
  create tests/unit/serializers/serializer-test.js  ⬅ should be `tests/unit/product/serializer-test.js`

I do support the idea of colocating route-related files. I believe we can find the right solution for this more easily, when we deprecate pods (start over) and simplify ember-cli / ember-source / ... (I'm not sure about implementation details for colocation).

I wrote a codemod for moving pods to standard Octane. When colocated route files are supported, we would then write a codemod to move files in controllers / routes / templates to the new folder structure.

[bertdeblock]

I feel that the current logic we have to support pods should remain. Once / if route components are an actual thing, we can re-evaluate I think? Because it seems that most developers use it for routes?

[luxzeitlos]

IMHO the way to get people away from pods for routes/controlles/templates is the same as for components: providing an alternative. We got colocation, and now there is no need for components to be pods. IMHO we just need to get rid of controllers and templates, something we really should do anyway, and the problem vanishes.

From my perspective there are two real blockers:

• query params.
• route templates
  • here this would have provided a path forward, but something similar would also work. but IMHO we need something rather sooner then later, and IMHO an ok enough solution now is much better then a perfect API in 2 years!

For me I currently even consider using more pods, because #731 probably won't be accepted. And while I started using the polyfill, the PR being open for ~2 years and currently there being a discussion that this is not the way to move forward, using pods is the only reasonable alternative. I really hope there is some movement forward here, because I want to get away from pods. Just there is nothing to go to.

[herzzanu]

I understand we don't want to support pods moving further. What are the reasons we don't want to support them? It looks like a lot of people benefit today from using pods. Can it be that we never taught them correctly? It looks like the original idea was to move all the resources under a pods folder like routes, components etc. This does not make much sense today. But it makes a lot of sense to be able to use a dedicated folder for the routes related folders and files.

[sandstrom]

I thought it was widely known and accepted to not use pods for new apps, and it came to my attention that we haven't officially deprecated them because we never officially supported them. So I think we should explore an RFC that makes it clear that we don't support them for new apps going forward.

For us this would be fine (we aren't using Pods).

Also, overall I like the idea of going through slightly outdated stuff and considering if they are still relevant. Since Ember has existed for a pretty long time (for a front-end framework), there are some parts that may not be relevant 2023.

By slimming them down (thoughtfully, and with migrating paths and clear deprecations, I think were making it easier for new people to start out with Ember).

All that said, there are probably people using the pods structure today, that may have more specific feedback on how we should tackle them.

But I wanted to write a note of appreciation and support for the overall direction!

[herzzanu]

I agree with @sandstrom, we should think again about old concepts and how we teach and use them, both now and in the future. At the same time, we should consider the reality of applications in production. On top of that, we also want to be aware of what is the industry standard. We know that by looking at other widely used and well know frameworks like Nuxt, Next or SvelteKit to name a few. Each of these frameworks has a way to "gather" all related routes/pages files and folders under one namespace (what we call pods).

Personally, I think we've looked at and taught the pods concept in the wrong way. The reason for that is that we teach using pods for both components and routes folders, where the real value comes from having "pods" for the routes. Components already have a "pods" folder called "components". I understand that the pods idea came naturally as the framework evolved outside of the views and partial concepts towards the concept of the components.

As a last thought, we probably don't need the pods idea these days, indeed. But we need a way to structure all routes related files and folders under one dedicated folder IMHO.

[herzzanu]

As @luxzeitlos mentioned above. If we get rid of the routes/controllers then indeed we don't need the pods idea anymore. If we want to remove the pods idea before getting there then indeed we need an alternative.

[Panman82]

As @luxzeitlos mentioned above. If we get rid of the routes/controllers then indeed we don't need the pods idea anymore. If we want to remove the pods idea before getting there then indeed we need an alternative.

While I know there are router discussions for Polaris Edition, I wasn't aware there is the possibility of routes going away all together... My understanding was that while controllers are going away, the route and template file would still exist (probably a route specific, template-only component basically). Those would defiantly benefit from something just like component co-location, which is basically why I use pods. So before depreciating pods, we should instead propose co-location for route related files so there is something to move to first (if a change in layout is needed anyway).

[runspired]

Just to re-iterate, deprecating pods entirely would mean deprecating the resolver entirely.

I really think people miss this point. The pods resolution strategy is not actually any different than the classic resolution strategy, it just additionally allows you to run the same strategy within a specific sub-folder.

What's more, the resolution strategy itself is a public API that can be configured by any application, either by configuring resolver middleware or by providing your own resolver which conforms to the interface (see for example the very awesome ember-strict-resolver project).

Embroider built applications still use the resolver, and there isn't a spec yet for how embroider-only applications ought to be structured in their file system: and there may never be, because the overall direction is that ember shouldn't care how your project is structured at all.

And that is another very very key point here: the future of Ember looks exactly like how most folks have used pods today, co-located files if you desire / arbitrary file structure overall. It looks like this not because any specific structure will be proposed, but because the embroider/broader-ecosystem-tooling-compat build story is that instead of this being a resolver concern, your files are correctly importable and findable by the build tool.

[runspired]

@ijlee2

In addition to a few codemods, even ember-data doesn't support pods well, because it causes ember-cli to generate test files incorrectly. If we set usePods to true, the test for every adapter, model, and serializer will get the same file name.

This just looks like a bug that's easy to fix and ought to be fixed. I've never noticed because I don't think I've ever used blueprints even once outside of doing maintenance on them 😅. I'd say I have half a mind to output adapter/model/serializer tests and modules in the classic structure even when usePods is true because that's the ideal for pods for those things anyway, but since all three concepts are going away (with adapter/serializer marked legacy already, and Model soon to follow in 5.x) this will be a moot point.

[jelhan]

Is moving pod support our into an addon an option? If I get @runspired right, it's based on public APIs. Or could be at least implemented using public APIs.

This may give us the best of both options:

• Ember's core projects (Ember CLI, ember-source, ember-data, embroider) don't need to care anymore about pods. Reduced maintenance costs seem to be main driver for this proposal.
• Teams using Pods can takeover maintenance.

It would even allow reducing pods to colocating route, route-template, and controller. That seems to be the only use case for pods today.

[sandstrom]

Adding to what @jelhan said.

If it's only about co-locating files, it sounds like it might be a build-level concern (Embroider configuration), where a webpack plugin (?) would be used to allow them to be looked up elsewhere.

I'm not saying it shouldn't be packaged as an addon. Depends on what ability addons have to influence the Embroider build process.

But maybe we don't even need an addon for it, maybe adding a 'recipe' to the Embroider docs is enough.