Migrate Ember services away from pod structure

On one of my Ember projects I noticed that my Services were for whatever reason using so pod layout:

❯ fd service.js
app/customers/service.js
app/preference/service.js
app/raven/service.js
...

Compare this to classic way to create services:

❯ ember g service customers --pod=false
installing service
  create app/services/customers.js

The former layout is not practical for several reasons:

• Those extra files are in the way when you decide that you want to change your route structure, because your route.js/controller.js/template.hbs files live in the same place.
• If you're looking for a service and you're not exactly sure about it's name, it's way easier to find it in one folder than multiple.

There is a neat trick to refactor all this in one go. You will just need nifty little renaming tool called mmv, which can use wildcards for file matching and capturing groups for renaming. If you're using homebrew on OSX, it's as simple as:

❯ brew install mmv

And then following command should do the trick:

❯ mmv -v "app/*/service.js" "app/services/#1.js"
app/customers/service.js -> app/services/customers.js : done
app/preference/service.js -> app/services/preference.js : done
app/raven/service.js -> app/services/raven.js : done
...

Much better. All services are neatly organised in one place.

---

Photo by The Matter of Food on Unsplash

Comments

[Jeldrik Hanschke]

I'm a little bit confused. app/services/foo.js is the default filesystem layout of Ember for years. app/foo/service.js is POD layout.

[Michal Bryxí]

You are very much correct. Sorry, I confused myself in the terminology. Yep I was really using pod layout in that project and I was describing the way to migrate back to non-pod (classic?) structure. Adjusted the article. Hope it matches the reality now.

[Bryan]

Unfortunately this will break any imports. I'm working on a codemod that does this including fixing imports. Nudge to me to get it published!

[Michal Bryxí]

Awesome. Happy to link to it at the end of the article as a better approach. People should not be forced to build this tooling themselves.

Re imports: Definitely true. In my case I'm just using standard @service and it will look it up fro me. No other exports / ad-hoc imports necessary in my case.