Firebase-tools: 배포 시 단일 리포지토리 지원

이것은 즉, 내 설정에서 작업 보인다 deploy 종목 루트에서 패키지까지 node_modules , 비록 package.json 그 아래에 위치에 대한 api/ 작업 공간 ( functions/ 대신 다른 폴더 이름을 사용했습니다. 여기에 수정해야 할 다른 것이 있습니까?

편집 : 또한, 나는 복사 package.json 에 api/dist 에 의해 사용되는 deploy .

// firebase.json
  ...
  "functions": {
    "source": "api/dist"
  },
  ...

따라서 2단계 중첩은 여전히 ​​루트 node_modules 성공적으로 해결합니다.

@dinvlad 리포지토리 를 공유할 수 있습니까?

@orouz는 불행히도 아직 아니지만 현재로서는 비공개 소스입니다.

누구든지이 문제를 해결할 수 있습니까? 간단한 예제 프로젝트를 공유하는 것은 매우 유용할 것입니다.

@audkar 현재 난 그냥 사용 lerna.js.org 그것은이다 run 이 폴더 구조와 각 하위 폴더에 NPM 스크립트를 실행하는 명령

- service1/
|  - .firebaserc
|  - firebase.json
- service2/
|  - .firebaserc
|  - firebase.json
- app1/
|  - .firebaserc
|  - firebase.json
- app2/
|  - .firebaserc
|  - firebase.json
- firestore/
|  - firestore.rules
|  - firestore.indexes.json
- etc...

각 서비스에 대한 firebase.json 파일이 서로를 짓밟지 않도록 하는 것은 사용자에게 달려 있습니다. 함수 그룹 및 다중 사이트 이름 타겟팅 을 사용하는 간단한 규칙은 이것이 Cloud Functions 및 Hosting에서 해결되었음을 의미합니다. Firestore/GCS 규칙에 대한 솔루션은 아직 없지만 분할하는 것이 이상적이지 않을 수 있습니다...

이전에 여기에서 논의됨 - https://github.com/firebase/firebase-tools/issues/1116

@jgedus 답변 감사합니다. 하지만 이 티켓의 문제는 다르다고 생각합니다. 원사 작업 공간을 사용하려고합니다. 그리고 Firebase 도구는 기능을 업로드할 때 심볼릭 링크 종속성을 선택하지 않는 것 같습니다.

아 맞다 그 토끼굴은 내가 피했어

문제가 무엇인지 자세히 설명해 주시겠습니까? 위에서 언급했듯이 api 및 app 작업 공간이 있는 베어 Yarn을 사용하고 yarn workspace api build && yarn workspace app build (각각에 특정한 build 스크립트 포함)를 사용하여 빌드합니다. 작업 공간). 빌드 스크립트
1) outDir 를 사용하여 TS 코드를 각각 api/dist 및 app/dist 컴파일합니다.
2) 해당 package.json 파일을 dist 디렉토리에 복사합니다.
3) _root_ 폴더에서 yarn.lock 를 dist 디렉토리로 복사합니다.

그럼 난 그냥 실행 yarn firebase deploy _root_ 폴더를, 그리고 그것을 집어 들고 모두 api/dist 및 app/dist 어떤 딸꾹질없이. 내 firebase.json 는 다음과 같습니다.

  "functions": {
    "source": "api/dist"
  },
  "hosting": {
    "public": "app/dist",

불행히도 아직 전체 코드를 공유할 수는 없지만 이 설정이 가장 중요합니다.

또한 내가 틀릴 수도 있지만 firebase deploy 스크립트가 실제로 node_modules 디렉토리를 사용하지 않는다고 생각합니다. dist 디렉토리에서 package.json 및 yarn.lock 를 선택하고 나머지는 수행한다고 생각합니다.

그건 사실이야. firebase.json에서 "functions.ignore"의 기본값은 다음과 같습니다.
["node_modules"] 업로드되지 않습니다. 나는 당신이 그것을 무시할 수 있다고 믿습니다
그러나 일부 로컬 모듈을 배송하려는 경우.

2019년 6월 17일 월요일 오후 6:58 Denis Loginov [email protected]
썼다:

또한 내가 틀릴 수도 있지만 Firebase 배포 스크립트가
실제로 node_modules 디렉토리를 사용하십시오. 나는 그것이 단지 집어 든다고 생각한다.
dist 디렉토리에서 cod, package.json 및 yarn.lock을 수행하고
쉬다.

—
이 스레드에 가입했기 때문에 이 메시지를 받고 있습니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/firebase/firebase-tools/issues/653?email_source=notifications&email_token=ACATB2U73VS2KIILUVRFFB3P3A6NPA5CNFSM4EOR24GKYY3PNVWWissue3TUL52HS4DFVREWSG43VMVBW63
또는 스레드 음소거
https://github.com/notifications/unsubscribe-auth/ACTB2U3Q2TLVBICRJ3B5OLP3A6NPANCNFSM4EOR24GA
.

@dinvlad 예, package.json 및 클라우드 사후 배포에 deps를 설치할 때 사용하는 잠금 파일이 필요합니다.

다른 문제에서 원래 설명된 시나리오는 작업 공간 내에서 공유 패키지를 사용하고 범위 호이스팅과 관련된 몇 가지 문제라고 생각합니다. 나는 이런 식으로 원사를 사용하지 않았기 때문에 내가 그곳에서 읽은 것으로만 추측할 수 있습니다.

@samtstern @jthegedus 감사합니다.

우리는 모두 다른 문제에 대해 이야기하는 것 같습니다. yarn workspaces 문제를 설명하려고 합니다.

문제가 있는 프로젝트

프로젝트 레이아웃

- utilities/
|  - package.json
- functions/
|  - package.json
- package.json

__./패키지.json_

{
  "private": true,
  "workspaces": ["functions", "utilities"]
}

_함수/패키지.json_

{
  <...>
  "dependencies": {
    "utilities": "1.0.0",
    <...>
  }
}

문제

함수 배포 중 오류:

Deployment error.
Build failed: {"error": {"canonicalCode": "INVALID_ARGUMENT", "errorMessage": "`gen_package_lock` had stderr output:\nnpm WARN deprecated [email protected]: use String.prototype.padStart()\nnpm ERR! code E404\nnpm ERR! 404 Not Found: [email protected]\n\nnpm ERR! A complete log of this run can be found in:\nnpm ERR!     /builder/home/.npm/_logs/2019-06-18T07_10_42_472Z-debug.log\n\nerror: `gen_package_lock` returned code: 1", "errorType": "InternalError", "errorId": "1971BEF9"}}

함수는 에뮬레이터에서 로컬로 잘 작동합니다.

시도한 솔루션

node_modules 업로드 중(_firebase.json_에서 functions.ignore ). 결과는 동일합니다.

utilities 가 _node-modules_ node_modules/utilities -> ../../utilities 에서 syslink로 생성되었기 때문이라고 생각합니다.

firebase-tools가 업로드할 때(역참조 없음) 심볼릭 링크된 모듈의 내용을 포함하지 않을 수 있습니까?

죄송합니다. firebase.json 있는 폴더를 명확히 하고 functions 대한 구성 섹션을 표시할 수 있습니까?

_firebase.json_은 루트 폴더에 있습니다. 구성은 표준이었습니다. 다음과 같이 smth:

  "functions": {
    "predeploy": [
      "yarn --cwd \"$RESOURCE_DIR\" run lint",
      "yarn --cwd \"$RESOURCE_DIR\" run build"
    ],
    "source": "functions",
    "ignore": []
  },
  <...>

symlink인 node_modules/utilities 를 제외하고 모든 것이 예상대로 배포되었습니다(_node_modules_ 포함).

다음과 같은 몇 가지 스크립트를 작성하여 이 문제를 해결할 수 있습니다.

• 각 작업 공간에 대한 패키지를 만듭니다( yarn pack ). 예를 들어 이것은 _utilities.tgz_를 생성합니다.
• 모든 출력을 특정 디렉토리로 이동합니다.
• 작업 공간 종속성에 tgz 파일을 사용하도록 _package.json_을 수정합니다. 예: dependencies { "utilities": "1.0.0" -> dependencies { "utilities": "file:./utilities.tgz"
• 해당 디렉토리를 Firebase에 배포

업로드하기 전에 출력 디렉토리 내용:

- dist
|  - lib
|  | -index.js
|  - utilities.tgz
|  - package.json <---------- This is modified to use *.tgz for workspaces

@audkar 오늘 나는 당신과 같은 문제에 부딪쳤습니다.

저는 Lerna와 Yarn 작업 공간 모두를 처음 사용합니다. 내가 이해하는 한 Lerna를 사용할 수도 있습니다. 어떤 식으로든 도움이 될까요?

해결 방법이 조금 복잡해 보입니다 🤔

또한 `--cwd "$RESOURCE_DIR"이 무엇인지 궁금합니다.

--cwd 는 "현재 작업 디렉토리"를 나타내고 $RESOURCE_DIR 는 소스 디렉토리(이 경우 functions 에 대한 값을 보유합니다. 이 플래그를 추가하면 yarn 가 root 대신 functions dir에서 실행됩니다.

@audkar 아 yarn workspace functions lint 및 yarn workspace functions build 동일한 작업을 수행할 수 있습니다.

@dinvlad 왜 dist 폴더를 대상으로 하고 거기에 물건을 복사하는지 명확하지 않습니다. dist에 빌드하지만 package.json은 그대로 두고 main을 dist/index.js 로 가리키면 모든 것이 동일하게 작동해야 합니다. 아니요? 그런 다음 소스를 api/dist 대신 api로 설정해야 합니다.

@dinvlad 귀하의 의견에서 yarn workspace 명령을 배웠지만 어떤 이유로 작동하지 않는 것 같습니다. 여기를 참조

여기서 주제를 조금 벗어나서 죄송합니다. 소음을 최소화하기 위해 SO에 주석을 달 수 있습니다.

@0x80 package.json 를 api/dist 복사하고 firebase.json 를 api/dist 지정하여 "빌드" 파일만 클라우드 함수 내에 패키징합니다. firebase.json 를 api 가리키면 어떻게 될지 잘 모르겠습니다. api/dist ( main package.json main 속성 ). 하지만 api/dist 가리키는 것이 더 깔끔하다고 생각했습니다.

yarn workspace , 나는 SO 에 응답했습니다 ;)

@dinvlad 그것은 당신이 가리키는 루트를 묶을

이제 @audkar와 유사한 해결 방법을 사용했습니다.

{
  "functions": {
    "source": "packages/cloud-functions",
    "predeploy": ["./scripts/pre-deploy-cloud-functions"],
    "ignore": [
      "src",
      "node_modules"
    ]
  }
}

그런 다음 pre-deploy-cloud-functions 스크립트는 다음과 같습니다.

#!/usr/bin/env bash

set -e

yarn workspace @gemini/common lint
yarn workspace @gemini/common build

cd packages/common
yarn pack --filename gemini-common.tgz
mv gemini-common.tgz ../cloud-functions/
cd -

cp yarn.lock packages/cloud-functions/

yarn workspace @gemini/cloud-functions lint
yarn workspace @gemini/cloud-functions build

그리고 packages/cloud-functions에는 추가 gitignore 파일이 있습니다.

yarn.lock
*.tgz

여기 나를 위해 일한 것이 있습니다

- root/
|  - .firebaserc
|  - firebase.json
- packages/
  | - package1/
  | - functions/
    | - dist/
    | - src/
    | packages.json

root/firebase.json :
```
{
"기능": {
"사전 배포": "npm --prefix "$RESOURCE_DIR" 빌드 실행",
"소스": "패키지/함수"
}
}
````

@kaminskypavel 은 packages/package1(또는 다른 형제 패키지)에 따라 달라지는 패키지/기능입니까?

@0x80 긍정적입니다.

모노레포에 대해 제가 근본적으로 잘못 알고 있는 부분이 있었던 것 같아요. 실제로 NPM에 공유 패키지를 게시하지 않고도 패키지를 공유하고 해당 패키지를 사용하여 앱을 배포할 수 있다고 가정했습니다.

Firebase 또는 Now.sh와 같은 배포는 일반적으로 코드를 업로드한 다음 클라우드에서 설치 및 빌드를 수행하기 때문에 이것이 불가능한 것 같습니다. 제가 맞습니까?

@kaminskypavel 귀하의 접근 방식을 시도했지만 작동하지만 먼저 내 패키지를 NPM에 게시한 후에야 작동합니다. 제 경우에는 패키지가 비공개이기 때문에 처음에 "찾을 수 없음" 오류가 발생했기 때문에 여기에 설명된 대로 클라우드 기능 패키지의 루트에 .npmrc 파일도 추가해야 했습니다

@audkar 공통 패키지를 NPM에 게시하고 있습니까, 아니면 저와 같이 게시되지 않은 공유 코드로 배포하려고 합니까?

@0x80 나는 이 이해에 대해 당신과 함께합니다. Firebase 함수 배포는 package.json에 명명된 모든 패키지가 배포 속도를 높이는 이름으로 npm에서 사용할 수 있다고 가정하는 것뿐이라고 (잘못) 생각합니다.

yarn 작업 공간 설정이 점점 더 대중화되면서 더 많은 사람들이 Firebase Functions에서 심볼릭 링크된 패키지를 사용할 수 없다는 사실에 놀랄 것이라고 생각합니다. 특히 배포할 때까지 제대로 작동하기 때문입니다.

npm이 작업 공간 에

이 문제는 1년이 넘었으므로 Firebase 측에서 계획(또는 계획 부족)에 대한 업데이트가 있습니까?

아주 멋진 기회라고 생각합니다. Firebase의 일련의 서비스는 좋은 monorepo 설정을 요구합니다.

이에 대해 +1, 클라우드 기능은 일반적으로 다른 앱과 일부 공통 코드(예: 인터페이스)를 공유해야 하며 이를 처리하는 좋은 방법은 monorepo(예: lerna) 또는 직접 심볼릭 링크를 사용하는 것입니다. 나는 후자를 취하고 일부 스크립트를 작성하여 해결했습니다. 개념은 매우 쉽습니다. functions 디렉토리 안에 필요한 것을 복사하고 나중에 제거합니다.

다음은 이 디렉토리 구조로 수행한 방법입니다.
```

• 뿌리/
  | - .firebaserc
  | - firebase.json
  | - ...
• 기능/
  | - src/
  | - 패키지.json
  | - pre-deploy.js
  | - post-deploy.js
  | - ....
• 공유/
  | - src/
  | - 패키지.json
  | - ....

content of `pre-deploy.js`

const fs = 요구("fs-extra");

const packageJsonPath = "./패키지.json";
const 패키지Json = 요구(패키지JsonPath);

(비동기() => {
대기 fs.remove( ./shared );
대기 fs.copy( ../shared , ./shared );

packageJson.dependencies["@project/shared"] = "file:./shared";

await fs.writeFile(packageJsonPath, JSON.stringify(packageJson, null, 2));

})();

content of `post-deploy.js`

const packageJsonPath = "./패키지.json";
const 패키지Json = 요구(패키지JsonPath);
const fs = 요구("fs-extra");

(비동기() => {
대기 fs.remove( ./shared );

packageJson.dependencies["@project/shared"] = "file:../shared";

await fs.writeFile(packageJsonPath, JSON.stringify(packageJson, null, 2));

})();

Then update `firebase.json` like this (add the build script if you need, I build before in my pipeline)

"기능": {
"소스": "기능",
"사전 배포": [
"npm --prefix "$RESOURCE_DIR" 사전 배포 실행"
],
"배포 후": [
"npm --prefix "$RESOURCE_DIR" 배포 후 실행"
]
},
```

빌드를 수행하면 dist 또는 lib 디렉토리 내부에 이제 함수와 공유라는 두 형제가 있어야 합니다(이는 공유 종속성 때문에 발생했습니다). 기능 업데이트해야합니다 package.json main 를 차례로 lib/functions/src/index.js 배포 작업을 할 수 있습니다.

지금은 해결되었지만 해결 방법이 아니라 해결 방법입니다. Firebase 도구가 실제로 심볼릭 링크를 지원해야 한다고 생각합니다.

@michelepatrassi 는 이 사례를 관리하기 위해 firelink 라이브러리를 만들었습니다. 내부적으로 rsync 를 사용하여 재귀 파일을 복사합니다.

https://github.com/rxdi/firelink

npm i -g @rxdi/firelink

기본 사용법
monorepo 접근 방식이 있고 패키지가 package.json 가 있는 현재 디렉토리에서 2단계 아래에 있다고 가정합니다.

package.json

  "fireDependencies": {
    "@graphql/database": "../../packages/database",
    "@graphql/shared": "../../packages/shared",
    "@graphql/introspection": "../../packages/introspection"
  },

firelink 실행하면 폴더와 관련된 패키지를 복사한 다음 기존 패키지를 로컬 모듈 설치 "@graphql/database": "file:./.packages/database", 로 매핑한 다음 firebase 명령을 실행하고 firelink 나머지 인수를 전달합니다.
기본적으로 firelink 은 packages 복사 및 package.json 수정 작업을 마치면 끝에 firebase 를 생성하기 때문에 firebase CLI를 대체합니다!

문안 인사!

우리는 이것에 물렸고 monorepos가 표준이 될 것이며 이것은 기본적으로 지원되어야 한다고 생각합니다.

여러분, 이 문제에 대한 간단한 해결책은 webpack을 사용하여 클라우드 기능을 번들로 묶고 번들 디렉토리에서 배포하는 것입니다. 여기에 제가 사용하고 있는 기본 webpack 파일이 첨부되어 있습니다. 빌드하는 동안 모노 리포지토리 내에서 해결된 종속성을 포함하여 모든 기능 코드를 최상위 폴더로 압축합니다(이 경우 webpack/cloud-functions , 구성한 모든 항목일 수 있음).

const path = require('path');

module.exports = {
  target: 'node',
  mode: 'production',
  entry: './src/index.ts',
  module: {
    rules: [
      {
        test: /\.tsx?$/,
        use: 'ts-loader',
        exclude: /node_modules/
      }
    ]
  },
  resolve: {
    extensions: ['.tsx', '.ts', '.js', '.json']
  },
  output: {
    filename: 'index.js',
    path: path.resolve(__dirname, '../../webpack/cloud-functions/dist'),
    libraryTarget: 'commonjs'
  },
  externals: {
    'firebase-admin': 'firebase-admin',
    'firebase-functions': 'firebase-functions'
  }
};

그리고 마지막으로 firebase.json 파일에서 배포를 위해 이 폴더를 참조하십시오.

{
  "functions": {
    "source": "webpack/cloud-functions"
  }
}

webpack/cloud-functions 폴더에도 package.json 파일이 있어야 합니다.

{
  "name": "cloud-functions",
  "version": "1.0.0",
  "scripts": {
    "deploy": "firebase deploy --only functions"
  },
  "engines": {
    "node": "10"
  },
  "main": "dist/index.js",
  "dependencies": {
    "firebase-admin": "8.9.1",
    "firebase-functions": "3.3.0"
  },
  "devDependencies": {},
  "private": true
}

이것은 테스트되고 작동합니다. 구글 클라우드 빌드를 사용하고 있습니다. 필요한 경우 추가 정보를 요청하십시오.

감사 해요,

@sowdri 공유 functions.predeploy 단계에서 webpack 빌드를 트리거합니까, 아니면 firebase deploy를 호출하기 전에 클라우드 빌드 스크립트에서 트리거합니까?

@0x80 cloud build 단계에서 빌드 중입니다. 따라서 firebase cli 에 따르면 JS로 빌드된 함수 집합일 뿐입니다.

@sowdri 예를 들어 주셔서 감사합니다. 우리는 AWS Lambdas / Serverless에 대한 과거 프로젝트에서 동일한 접근 방식을 사용하게 되었습니다. 도구가 원사 monorepo와 함께 작동하도록 하는 것보다 (Webpack) 번들을 업로드하는 것이 더 쉬웠습니다.

나는 또한 이것에 붙어 있습니다 .... 함수를 배포하려고 할 때까지 모든 것이 잘 작동했습니다 (심지어 firebase 에뮬레이터). :( firebase 팀이 곧 monorepos에 대한 지원을 추가할 수 있기를 바랍니다.

내 monorepo의 다른 패키지에 babel을 사용하므로 계속 사용하고 싶습니다. 다른 것이 없다면 나는 webpack을 시도 할 수 있습니다 ... 일부는 작동하는 것 같습니다.

편집: GitHub 패키지 레지스트리 를 사용하여 이 문제를 해결했습니다. 그래서 거기에 내 모든 패키지를 게시한 다음 travis 및 functions 서버에 대해 레지스트리를 설정하고 인증을 위한 토큰을 제공해야 합니다( .npmrc 를 통해 수행). ...우아한 솔루션인 것 같습니다. 여기에서 이 접근 방식에 대한 아이디어를 얻었습니다. https://medium.com/gdgeurope/how-to-use-firebase-cloud-functions-and-yarn-workspaces-24ca35e941eb

네, 이것도 물렸습니다. 모든 것이 firebase serve --only functions 에서 완벽하게 작동했지만 배포할 때 모듈을 찾을 수 없습니다.

나는 나를 위해 패키지를 빌드하기 위해 작은 스크립트를 작성하게 되었습니다. 이것은 내 디렉토리 이름과 일치하는 모듈 및 패키지 이름 사용과 같은 내 환경의 세부 사항을 반영하지만 다른 사람들에게 유용하기를 바랍니다.

``` "fs"에서 fs 가져오기;
"child_process"에서 child_process 가져오기;

const internalPackagesFull = new Map();

// 패키지의 모든 deps 찾기
const getDepsForPackage = (패키지 이름) => {
const packageDir = packageName.split("/")[1]; // 이것은 당신을 위해 변경해야 할 수도 있습니다
const packageSpecFileName = ../${packageDir}/package.json ;
const 패키지 사양 파일 = fs.readFileSync(패키지 사양 파일 이름);
const packageSpec = JSON.parse(packageSpecFile);
const packageInternalDeps = Object.keys(
packageSpec.dependencies
).filter((key) => key.includes("튜링")); // 이것은 당신을 위해 변경해야 할 것입니다

const 패키지TgzName = ${packageName.replace("@", "").replace("/", "-")}-v${ packageSpec.version }.tgz ;

internalPackagesFull.set(패키지 이름, {
패키지 사양 파일 이름,
패키지 사양,
패키지 디렉토리,
패키지 내부 뎁스,
패키지Tgz이름,
});

const packagesToProcess = packageInternalDeps.filter(
(internalDepName) => !internalPackagesFull.has(internalDepName)
);

packagesToProcess.forEach((internalPackageName) =>
getDepsForPackage(내부 패키지 이름)
);
};

const 패키지 이름 = JSON.parse(fs.readFileSync("./package.json")).이름;
child_process.execSync( cp ./package.json ./package.json.org );
getDepsForPackage(패키지 이름);

// 업데이트된 패키지 작성 - 공통 js를 사용하고 참조는 로컬 tgz 파일입니다.
[...internalPackagesFull.values()].forEach((internalDep) => {
const { packageSpec, packageSpecFileName, packageInternalDeps } = internalDep;

// 패키지 유형 변경
packageSpec.type = "commonjs"; // 이것은 당신을 위해 변경해야 할 수도 있습니다

// 패키지된 zip 파일이 될 dep의 위치를 ​​지정합니다.
packageInternalDeps.forEach((internalDepOfPackage) => {
const { 패키지TgzName } = 내부패키지 전체.get(internalDepOfPackage);
packageSpec.dependencies[internalDepOfPackage] = ./${packageTgzName} ;
});

fs.writeFileSync(
패키지 사양 파일 이름,
JSON.stringify(packageSpec, null, " ")
);
});

// 얀 빌드 및 팩 실행
[...internalPackagesFull.values()].forEach((internalDep) => {
노력하다 {
console.log( Buliding ${internalDep.packageDir} );
child_process.execSync("원사 빌드", {
cwd: ../${internalDep.packageDir} ,
});
console.log( Packaging ${internalDep.packageDir} );
child_process.execSync("원사 팩", {
cwd: ../${internalDep.packageDir} ,
});

if (packageName !== internalDep.packageSpec.name) {
  console.log(`Move to current directory ${internalDep.packageDir}`);
  child_process.execSync(
    `cp ../${internalDep.packageDir}/${internalDep.packageTgzName} .`,
    {
      cwd: ".",
    }
  );
}

} 잡기 (e) {
console.log(e);
}
});

// 표준 패키지 구조로 다시 이동
[...internalPackagesFull.values()]
.filter((internalDep) => 패키지 이름 !== internalDep.packageSpec.name)
.forEach((internalDep) => {
상수 {
패키지 사양,
패키지 사양 파일 이름,
패키지내부뎁스,
} = 내부Dep;

// change the package type
packageSpec.type = "module"; // THIS MAY NEED TO CHANGE FOR YOU

// specify the location of the dep to be the packaged zip file
packageInternalDeps.forEach((internalDepOfPackage) => {
  packageSpec.dependencies[internalDepOfPackage] = "*";
});

fs.writeFileSync(
  packageSpecFileName,
  JSON.stringify(packageSpec, null, "  ")
);

});
```

@sowdri에서 제공하는 솔루션을 사용했습니다(감사합니다!). 보조 package.json 포함하여 전체 dist/ 디렉토리를 자유롭게 삭제하고 다시 생성할 수 있도록 약간의 조정을 했습니다.

const path = require('path');
const CopyPlugin = require('copy-webpack-plugin');

module.exports = {
  ...,
  plugins: [
    new CopyPlugin({
      patterns: [{ from: 'package.dist.json', to: 'package.json' }],
    }),
  ],
};

그런 다음 패키지 루트에 다음 package.dist.json 을 유지합니다.

{
  "name": "@package/name",
  "version": "0.0.1",
  "engines": {
    "node": "10"
  },
  "main": "index.js",
  "dependencies": {
    "firebase-admin": "8.9.1",
    "firebase-functions": "3.3.0"
  },
  "private": true
}

이 파일에서 종속성을 제거하고 Webpack에 의존하여 이를 번들로 묶는 것이 가능할 수도 있지만(이 종속성을 기본 package.json 와 동기화 상태로 유지할 필요가 제거됨) 시도하지 않았습니다.

내 컴파일된 코드가 있는 출력 디렉터리에 디렉터리 구조를 보존하는 npm cpy 패키지를 사용하여 모든 관련 디렉터리 또는 Firebase 프로젝트에 대해 .firebaserc 및 firebase.json 를 복사하는 스크립트가 있는 단일 저장소를 사용합니다.

함수 배포를 위해 원래 package.json에서 package.json 를 만듭니다.

copyFiles.js 스크립트는 다음과 같습니다.

const cpy = require('cpy');
const fs = require('fs');
const package = require('./package.json');
(async () => {
    await cpy(['./../package.json', './**/*.json', './**/.firebaserc'], '../out/', {
        parents: true,
        cwd: 'src'
    });
    const dirs = fs.readdirSync('./out/');
    const newPkg = {
        main: package.main,
        dependencies: package.dependencies,
        engines: package.engines,
    }
    dirs.forEach(dir => {
        fs.writeFileSync(`./out/${dir}/package.json`, JSON.stringify({ name: dir, ...newPkg }));
    })
    console.log('Files copied!', dirs);
})();

배포를 위해 ./out/[project-name]/firebase deploy --only=functions 하거나 이에 대한 스크립트도 작성하십시오.

다음과 같은 Webpack 경고가 발생합니다.

/Users/me/Development/myproject/node_modules/firebase-functions/lib/config.js 61:23-42의 경고
중요 종속성: 종속성 요청은 표현식입니다.

이를 해결할 방법을 찾았습니까, 아니면 무시/억제하고 있습니까?

나는 경고 없이 일을 할 수 있었습니다 🥳 아래 구성으로 마무리했습니다. 특히 외부에 정규식 패턴을 사용하면 차이가 생겼습니다. 외부에 "firebase-functions"만 있으면 하위 모듈에서 가져온 모든 항목이 일치하지 않고 라이브러리가 여전히 번들에 포함되기 때문입니다.

번들 문제의 결과로 배포할 때 일부 애매한 @grpc 오류도 발생했습니다. 참고용으로 보관하는 것을 잊었습니다.

const path = require("path");
const CopyPlugin = require("copy-webpack-plugin");

module.exports = {
  target: "node",
  mode: "production",
  entry: "./src/index.ts",
  devtool: "inline-source-map",
  module: {
    rules: [
      {
        test: /\.tsx?$/,
        use: "ts-loader",
        exclude: /node_modules/,
      },
    ],
  },
  resolve: {
    extensions: [".tsx", ".ts", ".js", ".json"],
    alias: {
      "~": path.resolve(__dirname, "src"),
    },
  },
  output: {
    filename: "index.js",
    path: path.resolve(__dirname, "dist/bundled"),
    libraryTarget: "commonjs",
  },
  externals: ["express", /^firebase.+$/, /^@google.+$/],
  plugins: [
    new CopyPlugin({
      patterns: [{ from: "package.dist.json", to: "package.json" }],
    }),
  ],
};

별도의 package.dist.json이 필요하지 않은 것으로 나타났습니다. 이 파일을 가지고 있는 성가신 점은 물론 거기에 나열된 종속성을 업데이트할 때마다 수동으로 업데이트해야 한다는 것입니다. 그래서 그것을 잊는 것은 매우 쉽습니다.

대신 package.dist.json에 나열하지 _않은_ 모든 패키지를 devDependencies 목록으로 이동하고 webpack 복사 플러그인에서 해당 파일을 사용하세요. 이제 하나의 package.json만 처리할 수 있습니다. 🎉

또한 내 로컬 nodejs 버전이 배포된 노드 버전과 반드시 ​​같을 필요는 없습니다. 이제 firebase.json 파일에서 functions.runtime 를 지정할 수 있습니다. 따라서 package.json에서 engines 필드를 제거하고 대신 Firebase 구성에서 functions.runtime 를 "10" 또는 "12"로 설정합니다.

이것은 나를 위해 보이는 것입니다 :

{
  "functions": {
    "source": "packages/cloud-functions/dist/bundled",
    "runtime": "12"
  },
  "firestore": {
    "rules": "firestore.rules",
    "indexes": "firestore.indexes.json"
  },
  "emulators": {
    "functions": {
      "port": 5001
    },
    "firestore": {
      "port": 8080
    },
    "pubsub": {
      "port": 8085
    }
  }
}

소스 맵을 어떻게 처리하고 있습니까? devtool: "inline-source-map" 사용하여 내 기능을 webpack과 함께 묶으면 스택 드라이버 오류 보고에서 선택되지 않습니다. @sowdri

나는 내 프로젝트에서 같은 일을 겪었고 이것은 사이드 프로젝트를 위해 모든 패키지를 게시하고 싶지 않기 때문에 꽤 큰 문제였습니다. 여러 package.json 파일을 유지하거나 패키지 외부에서 빌드해야 하는 것은 성가신 일이었습니다. dep를 선택 사항으로 포함하면 Lerna가 계속 선택하고 업로드할 때 Firebase가 불평하지 않습니다.

아래 구성은 단일 package.json으로 심볼릭 링크된 dep 지원을 제공합니다!

패키지.json

{
  "name": "@your-package-name/functions",
  "version": "0.1.0",
  "scripts": {
    "build": "webpack"
  },
  "engines": {
    "node": "10"
  },
  "main": "dist/index.js",
  "dependencies": {
    "firebase-admin": "^8.10.0",
    "firebase-functions": "^3.6.1"
  },
  "optionalDependencies": {
    "@your-package-name/shared": "^0.1.0",
    "@your-package-name/utils": "^0.1.0"
  }
}

웹팩.config.js

const path = require('path')

// The cost of being fancy I suppose
// https://github.com/firebase/firebase-tools/issues/653

module.exports = {
  target: 'node',
  mode: 'production',
  entry: './src/index.ts',
  module: {
    rules: [
      {
        test: /\.tsx?$/,
        loader: 'ts-loader',
        exclude: /node_modules/,
        options: {
          configFile: 'tsconfig.build.json',
        },
      },
    ],
  },
  resolve: {
    extensions: ['.tsx', '.ts', '.js', '.json'],
  },
  output: {
    filename: 'index.js',
    path: path.resolve(__dirname, 'dist'),
    libraryTarget: 'commonjs',
  },
  externals: {
    'firebase-admin': 'firebase-admin',
    'firebase-functions': 'firebase-functions',
  },
}

Firebase.json

{
  "firestore": {
    "rules": "firestore.rules",
    "indexes": "firestore.indexes.json"
  },
  "functions": {
    "source": "packages/functions"
  },
  "emulators": {
    "functions": {
      "port": 5476
    },
    "firestore": {
      "port": 4565
    },
    "ui": {
      "enabled": true
    }
  }
}

저는 yarn 작업 공간을 사용하고 있지만 다른 package.json 파일에서 로컬 패키지 이름을 언급할 필요도 없습니다. Firebase와 Vercel 모두에 성공적으로 배포하고 있습니다.

무엇이 작동하는지 잘 모르겠습니다. 내 최상위 package.json에 다음 표준 구성이 있습니다.

"workspaces": {
    "packages": [
      "packages/*"
    ]
  },

yarn upgrade-interactive 하면 한 번에 모두 처리할 수 있기 때문에 각 /packages/* 폴더에 package.json이 있어도 상관 없습니다. 일부 패키지에서는 해당 범위에 대해 특별히 스크립트를 추가할 수 있는 것이 유용하다는 것을 알았습니다.

---- 편집하다 ----

프로젝트 참조와 함께 Typescript를 사용하고 있다고 언급하는 것을 잊었습니다. 그것과 관련이 있을 수 있습니다. Vercel의 경우 내 공유 코드를 번들에 포함하기 위해 next-transpile-modules를 사용하고 있습니다.

이 작업을 수행하기 위해 @0x80 및 @sowdri 와 유사한 설정을 사용하고 있지만 로컬 종속성을 devDependencies로 이동하는 대신(실제로 작동하지 않아 단계가 누락되었다고 생각함) copy-webpack-plugin , generate-package-json-webpack-plugin 를 사용하여 dist 폴더에 package.json을 빌드합니다. 이것은 결과 코드에 실제로 필요한 것에서 내 종속성 목록을 작성하므로 번들로 제공되거나 dev 종속성인 경우 결과 package.json에 포함되지 않습니다.

또한 webpack-node-externals 를 사용하여 외부를 설정하여 프로젝트 이름 접두사와 일치시키기 위해 정규식을 사용하는 심볼릭 링크된 모노레포 패키지를 제외한 모든 것을 외부로 만들었습니다. 또한 추가 외부로 게시된 @0x80 Firebase 패키지에 대한 정규식 표현식을 추가했습니다.

이것은 내 구성입니다

/* eslint-disable @typescript-eslint/no-var-requires */
const path = require("path");
const nodeExternals = require("webpack-node-externals");
const GeneratePackageJsonPlugin = require("generate-package-json-webpack-plugin");

const basePackage = {
  name: "@project/functions",
  version: "1.0.0",
  main: "./index.js",
  scripts: {
    start: "yarn run shell"
  },
  engines: {
    node: "12"
  }
};

module.exports = {
  target: "node",
  mode: "production",
  entry: "./src/index.ts",
  devtool: "inline-source-map",
  module: {
    rules: [
      {
        test: /\.tsx?$/,
        use: "ts-loader",
        exclude: /node_modules/
      }
    ]
  },
  resolve: {
    extensions: [".tsx", ".ts", ".js", ".json"],
    alias: {
      "@": path.resolve(__dirname, "src"),
      "@root": path.resolve(__dirname, "./"),
      "@types": path.resolve(__dirname, "src/@types"),
      "@utils": path.resolve(__dirname, "src/utils")
    }
  },
  output: {
    filename: "index.js",
    path: path.resolve(__dirname, "dist"),
    libraryTarget: "commonjs"
  },
  externals: [
    /^firebase.+$/,
    /^@google.+$/,
    nodeExternals({
      allowlist: [/^@project/]
    })
  ],
  plugins: [new GeneratePackageJsonPlugin(basePackage)]
};

웹팩을 사용하여 코드를 묶을 때의 또 다른 이점은 마침내 모듈 별칭을 사용할 수 있다는 것입니다. :)