여러 애플릿을 패키징하는 코드 세트 실습

비즈니스 시나리오: 현재 타로 애플릿을 유지 관리하고 있는데, 페이지와 모듈이 많고 일부 기능은 서로 관련이 없을 수 있습니다. 따라서 앱에서 일부 모듈을 추출하여 프로모션 및 새로운 풀을 위한 작은 프로그램을 다시 패키징할 것을 제안합니다.

프로세스에 대해 생각하기

Question & Answer

Q1. 여러 애플릿을 함께 유지 관리해야 할 수 있으므로 매번 이 애플릿을 변경한 다음 다른 프로젝트로 이동하여 변경할 수 없습니다.

A1: 특정 모듈을 위해 분할하지 않고 동일한 프로젝트에서 직접 유지 관리하는 것이 좋은 솔루션입니다.

1. 홈 페이지는 애플릿마다 다릅니다. 주제 애플릿의 홈페이지는 다른 애플릿에서는 필요하지 않을 수 있습니다.

A2: 홈페이지의 문제는 애플릿 패키지의 관리 배경을 통해 직접 해당 경로를 설정하거나 메인 패키지의 첫 번째 경로에 대한 홈페이지 경로를 설정하거나 구성 할 수 있습니다.

1. 테마 애플릿의 일부 페이지는 다른 애플릿에서도 필요하지 않을 수 있으며, 집계된 애플릿의 기본 패키지가 너무 클 수 있습니다.

A3: 특정 경로를 제거하기 위해 구성에 페이지가 필요하지 않은 특정 애플릿은 패키징되지 않습니다.

1. 홈 페이지 경로는 특정 애플릿에 맞게 동적으로 조정해야 합니다.

A4: 특정 애플릿의 판단에 따라 설정되는 홈 페이지 경로 변수를 설정합니다.

1. 관련 구성은 애플릿마다 다릅니다.

A5: 애플릿마다 다른 프로필을 설정합니다.

위의 과정은 기본적으로 하나의 패키지에 대해 조정해야 하는 과정이지만, 매번 저렇다면 귀찮을 것이고, 3~4개가 있다면... 동기화 유지가 필요한 애플릿은 어떨까요! 이를 최적화할 수 있는 방법이 있을까요? 어떻게 최적화할까요? 생각해보니... 이 파일들을 변경하기 위해 패키징을 한다면, 패키징할 때 어떤 애플릿이 패키징되는지 프로그램에 알려주고, 그것을 기준으로 판단하면 어떨까? 이 아이디어에서 process.env.NODE_ENV와 환경 설정 .env .env.development .env.production 등에 웹팩 상수를 설정하는 것을 생각했습니다. 이렇게 하면 나머지 프로세스를 어떻게 진행해야 하는지 정확히 알 수 있습니다.

구체적인 구현 과정

우선

npm 스크립트에서 --mode 개발로 process.env.NODE_ENV를 변경할 수 있으므로 특정 스크립트를 실행할 때 다른 애플릿을 구별하기 위한 매개 변수를 설정하는 방법이기도 합니다. Windows 컴퓨터에서 설정하려면 cross-env를 설치해야 하는데, 명령어는 다음과 같습니다:

 "scripts": {
 "build:weapp": "cross-env APP='TEST_APP' taro build --type weapp",
 "dev:weapp": "npm run build:weapp -- --watch",
 },

app.config.ts 파일에서 설정의 성공 여부를 테스트합니다.

console.log('process.env', process.env.APP);
export default defineAppConfig({
 pages: [
 'pages/index/index'
 ],
 window: {
 backgroundTextStyle: 'light',
 navigationBarBackgroundColor: '#fff',
 navigationBarTitleText: '',
 navigationBarTextStyle: 'black'
 }
})

구체적인 코드는 다음과 같습니다:

환경 설정 시 특정 값은 JSON.stringify로 처리해야 하며, 그렇지 않으면 process.env.APP의 값이 변수로 처리됩니다.

import { defineConfig, type UserConfigExport } from '@tarojs/cli'
import TsconfigPathsPlugin from 'tsconfig-paths-webpack-plugin'
import devConfig from './dev'
import prodConfig from './prod'
console.log('process.env.APP config', process.env.APP);
// https://taro-..com/docs/next/config#defineconfig-도우미 함수
export default defineConfig(async (merge, { command, mode }) => {
 const baseConfig: UserConfigExport = {
 projectName: 'taro-app-test',
 date: '2024-1-12',
 designWidth: 750,
 deviceRatio: {
 640: 2.34 / 2,
 750: 1,
 375: 2,
 828: 1.81 / 2
 },
 env: {
 APP: JSON.stringify(process.env.APP)
 },
 sourceRoot: 'src',
 outputRoot: 'dist',
 plugins: [],
 defineConstants: {
 },
 copy: {
 patterns: [
 ],
 options: {
 }
 },
 framework: 'react',
 compiler: 'webpack5',
 cache: {
 enable: false // Webpack 영구 캐시 구성, 켜는 것이 좋습니다. 기본 구성: https://..zone/docs/config-detail#cache
 },
 mini: {
 postcss: {
 pxtransform: {
 enable: true,
 config: {
 }
 },
 url: {
 enable: true,
 config: {
 limit: 1024 // 변환 크기 상한 설정하기
 }
 },
 cssModules: {
 enable: true, // 기본값은 false이며, CSS 모듈 함수를 사용해야 하는 경우 true로 설정합니다.
 config: {
 namingPattern: 'module', // 변환 모드, 전역/모듈의 값을 가져옵니다.
 generateScopedName: '[name]__[local]___[hash:base64:5]'
 }
 }
 },
 webpackChain(chain) {
 chain.resolve.plugin('tsconfig-paths').use(TsconfigPathsPlugin)
 }
 },
 h5: {
 publicPath: '/',
 staticDirectory: 'static',
 output: {
 filename: 'js/[name].[hash:8].js',
 chunkFilename: 'js/[name].[chunkhash:8].js'
 },
 miniCssExtractPluginOption: {
 ignoreOrder: true,
 filename: 'css/[name].[hash].css',
 chunkFilename: 'css/[name].[chunkhash].css'
 },
 postcss: {
 autoprefixer: {
 enable: true,
 config: {}
 },
 cssModules: {
 enable: false, // 기본값은 false이며, CSS 모듈 함수를 사용해야 하는 경우 true로 설정합니다.
 config: {
 namingPattern: 'module', // 변환 모드, 전역/모듈의 값을 가져옵니다.
 generateScopedName: '[name]__[local]___[hash:base64:5]'
 }
 }
 },
 webpackChain(chain) {
 chain.resolve.plugin('tsconfig-paths').use(TsconfigPathsPlugin)
 }
 },
 rn: {
 appName: 'taroDemo',
 postcss: {
 cssModules: {
 enable: false, // 기본값은 false이며, CSS 모듈 함수를 사용해야 하는 경우 true로 설정합니다.
 }
 }
 }
 }
 if (process.env.NODE_ENV === 'development') {
 // 로컬 개발 빌드 구성
 return merge({}, baseConfig, devConfig)
 }
 // 프로덕션 빌드 구성
 return merge({}, baseConfig, prodConfig)
})

그런 다음 홈 페이지에서 특정 process.env.APP를 가져올 수 있는지 다시 확인합니다.

이제 동적 패키징을 처리하는 일만 남았습니다.

동적 패키징

위의 과정이 끝나면 app.config.ts 구성 파일의 process.env.APP 값, 메인 패키지 페이지, 하위 패키지 페이지의 동적 구성 등을 통해 매우 쉽게 동적 패키징을 수행할 수 있습니다. 그러면 앱을 동적으로 패키징할 수 있습니다. 무엇을 해야 하는지 정확히 알았으니 이제 다음 작업을 시작할 수 있습니다!

구체적인 코드는 다음과 같습니다:

import { TEST_APP } from "./constants/app-type";
const pages = ["pages/index/index", "pages/bbb/index"];
const packageA_pages = ["pages/aaa/index", "pages/demo/index"]
if(process.env.APP === TEST_APP) {
 pages.unshift("pages/test/index")
 packageA_pages.push("pages/testa/index")
}
export default defineAppConfig({
 pages: pages,
 subPackages: [
 {
 root: "packageA",
 pages: packageA_pages,
 },
 ],
 window: {
 backgroundTextStyle: "light",
 navigationBarBackgroundColor: "#fff",
 navigationBarTitleText: "",
 navigationBarTextStyle: "black",
 },
});

특정 패키지의 차이점을 알아보려면 계속 읽어보세요.

일반 패키지 파일의 디렉터리입니다:

구성된 패키지 파일의 디렉터리입니다:

작은 프로그램에서 페이지가 작은 프로그램에 패키지화되지 않았으므로 위에서 발생한 문제를 해결하고 릴리스시 개발이 완료되고 파일을 수정할 필요가 없으며 해당 구성에서 app.config.ts 만 있으면 될 수 있으며 더 작은 프로그램의 패키징을 지원할 수 있음을 분명히 알 수 있습니다.

프로젝트 문서는 다음과 같은 구조로 되어 있습니다:

’ __tests__
│ └── index.test.js
├── babel.config.js
├── config
│ ├── dev.ts
│ ├── 색인.ts
│ └── prod.ts
├── 농담.config.ts
├── package.json
├── 프로젝트.config.json
├── 프로젝트.tt.json
├── src
│ ├── 앱.config.ts
│ ├── 앱.scss
│ ├── 앱.ts
│ ├── 상수
│ │ └── 앱 유형.ts
│ ├── 색인.html
│ ├── packageA
│ │ ├── 컴포넌트
│ │ └── 페이지
│ │ ├── AAA
│ │ ├── 데모 보기
│ │ └── 테스타
│ └── 페이지
│ ├── bbb
│ │ ├── 색인.config.ts
│ │ ├── 색인.module.scss
│ │ └── 색인.tsx
│ ├── 색인
│ │ ├── 색인.config.ts
│ │ ├── 색인.scss
│ │ └── 색인.tsx
│ └── 테스트
│ ├── 색인.config.ts
│ ├── 색인.scss
│ └── index.tsx
├── tsconfig.json
├── 유형
│ └── 글로벌.d.ts
└── 실.lock

요약

쓸모없는 쓰레기 하하하. 이 연습을 통해 물건에 대한 패키징 프로세스의 일부를 이해하고, 매개 변수 구성에서 패키징 명령을 배우고, 쓸모없는 코드에서 여러 애플릿의 패키징을 해결하고.... 작은 이득은 아닙니다.