Firebase-tools: Pre-serve hooks similar to pre-deploy

Created on 12 Mar 2018  路  13Comments  路  Source: firebase/firebase-tools

EDIT: Now that the local emulator (firebase emulators:start) is out this is even more important a feature to have, especially since the docs and init process document using TS as a language to write Cloud Functions.


Predeploy hooks are great! Given that serve emulates the deployment locally I must run the same scripts as predeploy before serve. It would be great if the firebase.json file also supported preserve scripts so I didn't have to duplicate the same scripts from my firebase.json in my package.json.

Version info

3.17.6

Platform Information

Ubuntu 17.10

emulator-suite feature request

Most helpful comment

This would be really useful when using typescript

All 13 comments

This would be really useful when using typescript

When you are doing typescript you have typically a tsc in watch mode running in addition to the devserver itself. The devserver that runs by starting "firebase serve" is doing hot reloads, so there is no need for a server restart between changes.
Running the tsc only on startup in a "preserve" hook doesn't make sense to me.

@mpoehler I would disagree.

I would like to test what I deploy, which would be production build of whatever I was compiling, TS or otherwise. I can see how it would be useful to serve the hot-reloading dev-server, but the current system doesn't support both cases. Adding a preserve hook serves both cases.

We agree that there should be more lifecycle hooks. We have an internal tracking bug for this (122552860), but would welcome discussion of additional hooks and/or PRs related to this.

Are there any updates on this topic?

I'm looking for a way to automatically invoke tsc --watch when I serve functions locally.

I'm also looking for a way to build and watch Vue source which is being deployed for hosting. I want to run vue-cli-service serve to auto rebuild any changes.

Any solutions to this other than having 3 terminal processes?

@bkendall Is that internal tracking number something we can see in Google Groups? and if so, can you link it here?

@jthegedus thanks for surfacing this old issues, this looks similar to a recent thought I had here:
https://github.com/firebase/firebase-tools/issues/2288

Although the difference here is that you want a specific preserve command which may be long-running.

I would say the best way to solve this issue is actually to use the concurrently package:
https://www.npmjs.com/package/concurrently

So your package.json would contain:

"scripts": {
  "serve": "concurrently 'tsc -w' 'firebase serve'"
}

That type of workaround is going to be much more flexible than anything we could provide. What do you think?

@samtstern The issue you linked is the one I am interested now what with the unified local emulator experience. As serve is different than the Emulator, and a number of people are now following this issue, I am hesitant to close this.

Does anyone else see themselves wanting to even use serve now firebase emulators:start is available?

@jthegedus we could close my issue instead, you were first after all!

There are two things at play here:

  1. I think functions.predeploy should be run exactly once before running the emulators, as mentioned in my issue. This would not require us to modify the firebase.json structure in any way or change any command-line arguments.
  2. There is room for a functions.preemulate hook or similar which would run alongside the emulators. This would be a change in firebase.json which is something we don't do lightly. However I am really hesitant to go into that when a module like concurrently solves it so much more generally.

While functionally similar, I don't think predeploy should be used for serve because only some of serve is locally executed.

Surely adding specific pre scripts to the firebaase.json file isn't too much effort given the core of the code is already written to support the predeploy script?

The commands:

  • firebase deploy
  • firebase emulators:exec
  • firebase emulators:start
  • firebase functions:shell
  • firebase serve

are all similar in that they run our code, so I'd expect each of them to support the similar pre scripts that were introduced for the deploy command.

At this time, since they are not supported consistently, I avoid using the predeploy script in firebase.json in favour of regular npm scripts, as it just muddies the water for anyone who doesn't know about pre script in firebase.json as it's not ubiquitous.

Also, given the emulators now support full Hosting with Functions locally, I would expect serve to be deprecated.

@jthegedus agree it's not "hard" but it's one more thing to support/document so i just want to make sure it's actually beneficial. As you said the "pre" scripts are kind of spotty and generally not as useful as just making your own npm scripts which are much more explicit.

We probably won't deprecate serve since it's been so popular for so long and there are so many blogs/guides/videos out there telling people to use it. But we'll definitely stop recommending it from our side, emulators:start is the future.

@jthegedus thanks for surfacing this old issues, this looks similar to a recent thought I had here:

2288

Although the difference here is that you want a specific preserve command which may be long-running.

I would say the best way to solve this issue is actually to use the concurrently package:
https://www.npmjs.com/package/concurrently

So your package.json would contain:

"scripts": {
  "serve": "concurrently 'tsc -w' 'firebase serve'"
}

That type of workaround is going to be much more flexible than anything we could provide. What do you think?

npm-run-all could be a better solution, cause concurrently sends 2 sigint and firestore doesn't terminate correctly

This would be beneficial for Firebase Hosting too: I'm using Vue and need to compile files to test with the new Emulators suite.

Was this page helpful?
0 / 5 - 0 ratings