refactor (functions): restructure project setup #124
Conversation
|
|
I would leave the webpack config in the |
|
Also, we get this annoying warning in the admin front end now:
The issue is already resolved and the error should go away with the next firebase release. |
|
Visit the preview URL for this PR (updated for commit dcdc944): https://admin-social-income-prod--pr124-restructure-function-9s8cjzz7.web.app (expires Sat, 15 Oct 2022 16:32:08 GMT) 🔥 via Firebase Hosting GitHub Action 🌎 |
| import { IconButton, Tooltip } from '@mui/material'; | ||
| import { getFunctions, httpsCallable } from 'firebase/functions'; | ||
|
|
||
| export default function CallDummyFunctionButton() { |
|
|
||
| // algolia search | ||
| export const ALGOLIA_APPLICATION_ID = process.env.REACT_APP_ADMIN_ALGOLIA_APPLICATION_ID; | ||
| export const ALGOLIA_SEARCH_KEY = process.env.REACT_APP_ADMIN_ALGOLIA_SEARCH_KEY; | ||
|
|
||
| // production envs | ||
| export const FIREBASE_CONFIG = { |
| "scripts": { | ||
| "build": "tsc", | ||
| "build:watch": "tsc --watch", | ||
| "build:webpack": "webpack --config webpack.config.js", |
There was a problem hiding this comment.
for what are we requiring now the webpack? For the final deployment?
| @@ -3,6 +3,6 @@ | |||
| "version": "0.1.0", | |||
| "private": true, | |||
| "devDependencies": { | |||
| "@camberi/firecms": "2.0.0-alpha.30" | |||
| "@camberi/firecms": "2.0.0-alpha.37" | |||
There was a problem hiding this comment.
I think it would be nice if the shared package doesn't have a dependency to the firecms.
What do you think of the approach I had in https://github.com/socialincome-san/public/pull/86/files#diff-eb15213d223e369551834a6ab5f0831a9a4484dfe9a44dabb2e29f91898f84ac where I copied the EntityReference implementation into the shared package? It's the only dependency we use, and then we can get rid of this one.
Makes the shared and therefore functions package much slimmer and faster.
There was a problem hiding this comment.
Hmm, but isn't that a problem when the dependent object changes? If it's just a devDependency, I don't see the problem. It will be in your node_modules folder anyway because it's being used in another project.
There was a problem hiding this comment.
Fair enough. Feels conceptually wrong to me that the functions have a compilation dependency to the firecms, but we can still iterate over it later.
npm ERR! Error: Missing script: "functions:test"
To see a list of scripts, run:
npm run
npm ERR! in workspace: @socialincome/admin@0.1.0
npm ERR! at location: /home/node/admin
npm ERR! Missing script: functions:test
npm ERR! A complete log of this run can be found in:
npm ERR! /home/node/.user/.npm/_logs/2022-10-08T15_06_34_214Z-debug-0.log
make: *** [functions-test] Error 1
~/code/public restructure-functions *1 ?2 ❯ make functions-test
should that work?
There was a problem hiding this comment.
Sorry my bad cached container.
Ah, haven't seen this comment during my review. Make sense 👍 |
mkue
changed the title
@andrashee, I think this resolves most of the issues we discussed. Let me know what you think of the new structure.
I think a single
firebase.jsonfile makes sense because everything we deploy is in a single Firebase project. We should switch to multiplefirebase.jsonfiles once we have more than one active project.FYI, I switched back to using
tscfor building the functions because I got the following error when I tried to deploy the functions that were build with webpack.I removed the
@socialincome/shareddependency from thepackage.jsonand import the code with relative paths again. Like this, it works at least.The
firebase deploycommand does not seem to like monorepos with npm workspaces. We should keep an eye on this issue: firebase/firebase-tools#653.