Conceptual Understanding

[AdditionAddict]

Hello,

I'm taking a deep dive into this repo creating my own from scratch, getting an understanding of the why behind this repo.

My understanding so far,

• a generated firebase app is based off a node app except we copy over the relevant firebase files
• we have a firebase.appname.json as the root in order to access /dist
• per stackoverflow the source points to the app which includes the package.json that normally gets generated inside the /functions folder and defines the engine used
• the build requires installing the dependencies inside the /dist/apps/appname folder and including a package.json

Can I check if this is correct so far and if there's anything to be aware of as I dive deeper?

Additionally. do you have any recommended learning material that helped you create this repo? Especially anything on executors.

Kind regards,
Andrew

[simondotm]

Hi @AdditionAddict ,

So this repo was originally created with two motivations:

1. That I could use Nx node libraries in my Firebase projects to share common code and structure my Firebase Functions code better
2. So that I could use more than one Firebase project in my Mono-repo

At the time, there were no Firebase plugins that supported this, so I wrote this plugin.

The reason why we copy built libraries at deployment time is because the Firebase SDK used to require all code related to functions deployment to be located/reachable within some single directory that the functions firebase configuration points to.

So yes, your understandings are correct.

However, three significant things have happened since this plugin was first created:

1. Nx have a release cadence that is frankly dizzying - their internal API's keep changing and not all of their documentation is kept upto date. As a result, this plugin has been difficult to maintain in alignment with Nx versions. I have tried a couple of times to refactor this plugin to maintain compatibility but I have found it has always been very time-consuming to comprehend the continually changing architecture of Nx plugins and adapt accordingly.
2. The latest Firebase SDK supports new directives in the configuration that allow for codebases, which I now believe is going to be a better approach for using Firebase in a mono-repo.
3. I also believe there are clearer opportunities now to use webpack as way to bundle deployed functions with only the code and dependencies that are used by each firebase function, and reduce the storage footprint of deployed functions (which consumes free tier resources if not managed well).

Due to changes in my career over the last two years I have had limited time to return to this project, but I have an ongoing side-project that would benefit from 2 and 3 above and my intention is to try and incorporate these approaches in a all-new version of this plugin.

As for recommendations for learning materials, I simply used the Nx documentation and similar plugins to figure things out.

Best,
Simon

[AdditionAddict]

Appreciate the above, this is helpful.

[AdditionAddict]

For emulators at least, 2 seems to be blocked by firebase/firebase-tools#4878

[simondotm]

@AdditionAddict since I posted that reply to you, this plugin has been completely updated to now use esbuild to bundle function code into codebases that are deployed.

So 2+3 are now what we use in this plugin.

Regarding the issue you linked, I think this is an edge case. In practice I use the emulator to test all functions in my workspace.