Closed JeanRemiDelteil closed 6 years ago
Thanks for the feature request, but Firebase Hosting tries to remain agnostic to the actual tooling you're using to build your front end. Introducing this behavior would mean that we are adding additional code dependencies and runtime CPU usage to firebase-tools
for a practice that is by no means universal at this time.
What we would like to do is provide better ways to run firebase serve
along-side your existing toolchain. Nothing specific to talk about here yet, but it's something we're looking into.
It would be awesome if we could run firebase serve
while providing a custom file provider, as superstatic does !
My try at solving this issue resulted in a combined server, first from poly-serve to prepare the files, then with superstatic to easily apply the existing server logic. It's far from ideal, but working.
Version info
v3.19.3
Platform Information
All
Steps to reproduce
On a project that use the latest Javascript imports and NPM package (for example: Polymer) try running the firebase server.
For example the https://github.com/Polymer/pwa-starter-kit can be deployed via
firebase deploy
but can not be tested withfirebase serve
.This defeats the purpose of a one command server which we all love.
Expected behavior
The app can be served with
firebase serve
Actual behavior
The app can only be served with
polymer serve
WHY ?
Issues lies in the javascript import Node module resolution:
while front javascript imports like:
This way of writing import is not in the ECMA specs for browser Javascript, however the polymer team and a lot of front-end libraries are now using NPM to publish front-end packages.
To support using NPM packages in the development of Firebase hosted site, the CLI should modify the import on-the-fly, like
polymer serve
already does.I have to stress that the issue only lies when developing and testing the site, not when deploying. This is because a build step correctly re-write those imports / bundles them.