Deployed application uses wrong index.html file #2
Comments
|
I'm afraid this has to do with the post-processing the provider we're using to prototype this beta does on the files uploaded. We're working on removing this feature soon, or at the very least allowing you to disable it. Thanks for your patience |
|
Thanks for response, Firebase hosting is a great service and it was easy to work around these small deployment glitches. |
|
This should now be fixed. Thanks for the interest |
|
Hello, |
|
@azucenareyes Check your firebase.json file Edit the line "public": "public" to "public": "app", or any other directory where your app content resides. That will help you. |
|
The problem is when firebase is creating the index file, it overwrites the one created by react. So what you have to do is run all the firebase code (minus deploy), then rerun 'npm run build' to get react to recreate the index file you need in the build directory, then change the |
The primary purpose of this change is to introduce the "discovery"
subpackage of "runtimes". This package is a common utility that all
runtimes will use to discover their backend spec based on the "container
contract" being finalized currently.
The container contract says that we must interact with customer code
using tools we'd have in a docker container: a fully-contained directory
of code, a "run" command, and environment variables. Backend specs can
be discovered as:
1. The file /backend.yaml at the root of the container
2. The response to http://localhost:${ADMIN_PORT}/backend.yaml when
running the container's RUN command with ADMIN_PORT set to a free
port.
The golang runtime fulfills #2 through two steps:
1. The Functions SDK includes the "codegen" package that reads the
customer code and creates an "autogen" main package that runs
the customer code as the Firebase runtime (skeleton implementation
currently).
2. We then start up the Firebase runtime with ADMIN_PORT set and
fetch /backend.yaml
After this + a minor fix to the template code, we have working Go
deploys!
I also moved gomod parsing into its own file to keep index.ts to a
minimal set of things that aren't easily unit tested. Unfortunately
the diff is largr than it needs to be now.
* Further improve function initialization
The primary purpose of this change is to introduce the "discovery"
subpackage of "runtimes". This package is a common utility that all
runtimes will use to discover their backend spec based on the "container
contract" being finalized currently.
The container contract says that we must interact with customer code
using tools we'd have in a docker container: a fully-contained directory
of code, a "run" command, and environment variables. Backend specs can
be discovered as:
1. The file /backend.yaml at the root of the container
2. The response to http://localhost:${ADMIN_PORT}/backend.yaml when
running the container's RUN command with ADMIN_PORT set to a free
port.
The golang runtime fulfills #2 through two steps:
1. The Functions SDK includes the "codegen" package that reads the
customer code and creates an "autogen" main package that runs
the customer code as the Firebase runtime (skeleton implementation
currently).
2. We then start up the Firebase runtime with ADMIN_PORT set and
fetch /backend.yaml
After this + a minor fix to the template code, we have working Go
deploys!
I also moved gomod parsing into its own file to keep index.ts to a
minimal set of things that aren't easily unit tested. Unfortunately
the diff is largr than it needs to be now.
* PR feedback
* Further improve function initialization
The primary purpose of this change is to introduce the "discovery"
subpackage of "runtimes". This package is a common utility that all
runtimes will use to discover their backend spec based on the "container
contract" being finalized currently.
The container contract says that we must interact with customer code
using tools we'd have in a docker container: a fully-contained directory
of code, a "run" command, and environment variables. Backend specs can
be discovered as:
1. The file /backend.yaml at the root of the container
2. The response to http://localhost:${ADMIN_PORT}/backend.yaml when
running the container's RUN command with ADMIN_PORT set to a free
port.
The golang runtime fulfills firebase#2 through two steps:
1. The Functions SDK includes the "codegen" package that reads the
customer code and creates an "autogen" main package that runs
the customer code as the Firebase runtime (skeleton implementation
currently).
2. We then start up the Firebase runtime with ADMIN_PORT set and
fetch /backend.yaml
After this + a minor fix to the template code, we have working Go
deploys!
I also moved gomod parsing into its own file to keep index.ts to a
minimal set of things that aren't easily unit tested. Unfortunately
the diff is largr than it needs to be now.
* PR feedback
In our app the public directory specified in firebase.json contains several HTML files. The main is called "index.html", the others are "index-full.html" and "facebook-channel.html". After "firebase deploy" the "index-full.html" becomes the default index file and following URLs all load contents of the same file "index-full.html":
If "index-full.html" was renamed to "index-full.html-off", then the correct "index.html" is picked up as the default index file.
The text was updated successfully, but these errors were encountered: