TypeScript를 사용한 AWS Lambda 함수용 Webpack 5 빌드

이전 게시물에서 매일 밤 자정에 AWS Lambda 함수로 실행되는 self-destructing tweets에 대해 썼습니다.

해당 게시물은 코드 자체에 관한 것이지만 대부분의 AWS CDK 인프라 정보는 cron 타이머에서 AWS Lambda를 실행하는 방법을 보여 주는 이전 게시물sending a serverless Slack message에 작성되었습니다.

오늘의 포스트는 이것들을 연결하는 짧은 개요가 될 것입니다: 그것은 내가 어떻게 Twitter 포스트의 TypeScript 코드를 노드 모듈과 묶고 배포를 위해 준비했는지 보여줍니다.

폴더 구조



나는 여기서 가정을 하고 있다. 내가 일반적으로 Lambda에 대해 가지고 있는 가장 "복잡한"설정은 TypeScript로 작성하고 변환을 위해 Babel을 사용하는 것입니다.

이것이 대부분의 사람들에게 친숙한 입장이 될 것이라는 점을 감안할 때 이것으로 작업합시다.

다음은 이 구조를 따르는 대부분의 람다가 함수 폴더 내에서 어떻게 보이는지입니다.

.
├── nodemon.json
├── package-lock.json
├── package.json
├── src
   ├── index.local.ts
   ├── index.ts
   └── function.ts
├── tsconfig.json
├── .babelrc
└── webpack.config.js


Nodemon 파일을 제외하고 빌드의 중요한 부분은 기본적으로 .babelrc , src/index.tswebpack.config.js 입니다.

또한 index.tsindex.local.ts 파일이 모두 있음을 알 수 있습니다. 내 프로젝트의 index.ts는 일반적으로 람다의 진입점입니다. 여기서 index.local.ts 파일은 일반적으로 실행할 수 있는 코드에 대해 람다 처리기를 교체하는 로컬 개발에 사용됩니다.

둘 다 일반적으로 다른 파일(여기서는 function.ts 로 표시)에서 주요 기능을 가져오고 그냥 호출합니다.

Webpack will bundle everything into one file later, so it is fine for me to structure the folder however I see fit.



자신의 프로젝트 설정



TypeScript 람다가 포함된 새로운 npm 프로젝트 내부에서 필수 Babel 및 Webpack 종속성을 추가해야 합니다.

npm i --save-dev \
  # install required babel deps
  @babel/core \
  @babel/preset-env \
  @babel/preset-typescript \
  # webpack deps and loaders required
  webpack \
  webpack-cli \
  babel-loader \
  cache-loader \
  fork-ts-checker-webpack-plugin \
  # finally install TypeScript
  typescript


설치가 완료되면 Babel과 TypeScript를 설정할 수 있습니다.

Babel 실행 명령 파일


.babelrc 내부에 다음을 추가합니다.

{
  "presets": [
    [
      "@babel/preset-env",
      {
        "targets": {
          "node": "12"
        }
      }
    ],
    ["@babel/preset-typescript"]
  ]
}


Babel에 익숙하지 않은 사용자를 위해 @babel/preset-env@babel/preset-typescript 플러그인을 사용하도록 지시하고 env 사전 설정에 몇 가지 구성 옵션을 추가하여 대상 노드 12(이는 일반적으로 AWS 람다에서 대상)를 지정합니다.

TypeScript 설정



이 부분은 취향에 맞게 조정해야 하지만 Twitter 봇에 대한 구성은 다음과 같습니다.

{
  "compilerOptions": {
    "module": "es2015",
    "target": "esnext",
    "outDir": "./dist",
    "strict": false,
    "types": ["node"],
    "resolveJsonModule": true,
    "moduleResolution": "node",
    "noUnusedLocals": true,
    "noUnusedParameters": true,
    "noImplicitReturns": true,
    "noFallthroughCasesInSwitch": true,
    "esModuleInterop": true,
    "lib": ["ES2020.Promise"]
  },
  "include": ["src/**/*"],
  "exclude": ["node_modules", "**/*.test.ts"]
}


Webpack을 사용하고 있다는 점을 감안할 때 위의 구성은 outDir 등으로 복잡할 필요는 없지만 원하는 옵션을 파악하는 데 맡기겠습니다.

웹팩



이 예에서는 Webpack 5를 사용하고 있다고 예상합니다.
webpack.config.js에서 :

const path = require("path")
const ForkTsCheckerWebpackPlugin = require("fork-ts-checker-webpack-plugin")

module.exports = {
  mode: "production",
  entry: "./src/index.ts",
  resolve: {
    extensions: [".js", ".jsx", ".json", ".ts", ".tsx"],
  },
  output: {
    libraryTarget: "commonjs",
    path: path.join(__dirname, "dist"),
    filename: "index.js",
  },
  target: "node",
  module: {
    rules: [
      {
        // Include ts, tsx, js, and jsx files.
        test: /\.(ts|js)x?$/,
        exclude: /node_modules/,
        use: [
          {
            loader: "cache-loader",
            options: {
              cacheDirectory: path.resolve(".webpackCache"),
            },
          },
          "babel-loader",
        ],
      },
    ],
  },
  plugins: [new ForkTsCheckerWebpackPlugin()],
}


람다의 로컬 개발에 Webpack을 사용하지 않는다는 점을 감안할 때 항상 프로덕션용으로 설정되어 있습니다.

여기에서 Webpack에 src/index.ts를 진입점으로 설정하고 commonjs로 변환하도록 지시합니다.

Babel 및 Cache 로더를 설정하여 해당 진입점에서 찾은 모든 ts 또는 js 파일을 테스트하고 컴파일합니다.

노드 모듈 번들을 피하는 Node Externals를 사용하지 않는다는 점을 감안할 때 필요한 모든 노드 모듈도 출력으로 컴파일됩니다.

즉, 노드 모듈을 설치하지 않고 프로젝트를 실행하는 dist/index.js의 출력은 AWS Lambda에 적합합니다!

빌드 실행


"build": "webpack""scripts" 파일의 package.json 키에 입력하면 롤 준비가 완료됩니다!
npm run build 를 실행하고 Webpack이 마법을 작동하게 한 다음 dist/index.js 에서 단일 파일 출력을 확인하십시오.

프로젝트 테스트



AWS CDK로 배포하기 전에 빌드를 테스트하기 위해 lambda-local을 사용합니다. TypeScript/JavaScript 프로젝트에 완벽한 Nodejs를 대상으로 합니다!

웹 사이트의 지침에 따라 설치하고 소용돌이를 일으키십시오! 일이 순조롭게 진행된다면 배포에 자신감을 가질 수 있습니다.

결론



이 게시물은 순전히 빌드 프로세스에 초점을 맞췄습니다. 소개에서 언급했듯이 내 다른 게시물 중 일부는 람다 ​​함수 작성과 실제 AWS CDK 배포에 대해 다룰 것입니다.

리소스 및 추가 읽을거리


  • Self-Destructing Tweets
  • Sending a serverless Slack message
  • lambda-local

  • 이미지 크레디트: Jess Bailey

    원래 내blog에 게시되었습니다. 더 많은 숨겨진 보석을 보려면 Twitter에서 저를 팔로우하십시오.

    좋은 웹페이지 즐겨찾기