Deploying Ember-CLI app with Firebase

Ember CLI
1

So I’m piddling around with Ember-CLI and I deployed it with Firebase’s hosting tools.

I have a number of issues I could use a hand with.

  1. my application automatically does a transitionTo('list'). I only have one real route. When I call firebase open from the command line it opens my app at https://emberfireapp.firebaseapp.com . It loads and works great. However, when you reload the page or try to navigate directly to https://emberfireapp.firebaseapp.com/list it gives a 404 page. Why is that and how do I fix it?

  2. When I first deployed it I forgot to change the standard “Welcome to Ember JS” header. So I went and changed it, did ember build --environment production and then firebase deploy. When I open the app it’s still the previous header. Is this a fubar with Firebase not overriding the previous build, or is the CLI not building things right? (note: I set the public key in my firebase.json to ./dist. Also, when I run ember server --environment production it loads all the production assets`

Thanks.

2

Also, I just checked to see if Firebase was deploying the app bassed off of the last commit. I committed things, even pushed it to my GitHub repo and deployed it again. Still didnt help.

– Update: I just did ember build without the production flag, did firebase deploy and it carried over the changes. Was I doing something wrong when I tried the production settings?

3

I see this link now allows direct navigation to sub-routes. How did you fix this as I am having this same issue.

Thanks in advance.

4

Sorry for not replying sooner. I have been remiss in my Ember message board attention.

I had to update my firebase.json to the following:

{
  "firebase": "emberfireapp",
  "public": "./dist",
  "ignore": [
    "firebase.json",
    "**/.*",
    "**/node_modules/**"
  ],
  "rewrites": [ {
    "source": "**",
    "destination": "/index.html"
  } ]
}

The rewrites section ensures that all navigation reroutes to index.html, and from there ember takes over.

Hope that helps

2 Likes
5

I made an addon that tries to help wrap this logic up a la this divshot addon. If it is useful for people I’m happy to keep iterating on it.

1 Like
7

I had same issue (404 page), but your answer fixed my issue, Tnx :smiley:

This may help to improve knowledge about firebase.json

Solution is:

  {
          "firebase": "emberfireapp",
          "public": "./dist",
          "ignore": [
            "firebase.json",
            "**/.*",
            "**/node_modules/**"
          ],
          "rewrites": [ {
            "source": "**",
            "destination": "/index.html"
          } ]
        }
8

does this rewrite asserts path?

1 Like
9

Yes it does - I just ran into this issue. At least for my app it doesn’t make sense to have missing assets redirected to /index.html.

I’m playing around with www.globtester.com to come up with a way to add rewrites while ignoring the assets path. As far as I know you can’t just add a rewrite that does something like { "source": "/assets/**", "destination": "" } to have it ignore that folder.

The best I’ve come up with so far is /!(assets)/** - according to globtester that should work, but a path like /assets-rock/stuff will not get a rewrite (honestly I’m not sure why, since I have a / right after the assets). Not ideal, but it’ll work for my purposes at least - however it doesn’t actually work when pushed to firebase. It still rewrites everything.

Has anyone found a solution for this yet?

10

You can find a detailed and working solution in this article, search for firebase: www.yoember.com

11

@zoltan, that article says the same thing as this post - to use "**" as a source. That will still end up rewriting the assets folder, which isn’t mentioned in that article.

After a little more playing around, I found that /!(assets)/** did actually work - maybe I had a typo originally. But now you get the default 404.html file, which could cause some issues depending on the asset you’re trying to fetch.

For example, in my dev server I’ll get a 404 for a json file that doesn’t exist, and the external library I’m using is smart enough to then ignore it as an empty file. However, with the firebase rules it’ll try to parse the default HTML page as json, which causes an error. I had to fetch the file manually, accounting for 404s, and pass the JSON manually into the external library. It’s still not an ideal solution, mainly because it’s different on dev than live so there can be some gotchas when deploying live.

1 Like
12

I keep finding some caveats. It turns out /!(assets)/** causes issues with routes that don’t have an extra slash in them. So /hello would fail but /hello/ or /hello/world would be fine.

I ended up doing /!(assets)**, which of course wouldn’t work for you if you have a route like /assets-are-awesome.