일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | 6 | 7 |
8 | 9 | 10 | 11 | 12 | 13 | 14 |
15 | 16 | 17 | 18 | 19 | 20 | 21 |
22 | 23 | 24 | 25 | 26 | 27 | 28 |
29 | 30 | 31 |
- Modular Architecture
- wasm
- Run Script
- Dependencies.swift
- 아키텍쳐
- tuist 4
- SPM
- rethrows
- Architecture
- Swift-Web
- Swift
- 4.0.0
- Swift Package Manager
- SwifWeb
- dependencies
- Module
- Prod
- Stencil
- XCConfig
- Build Phase
- 모듈화
- 메모리 구조
- SwiftLint
- Publish
- ios
- swiftwasm
- uFeature
- Tuist
- Tuist 모듈화
- Micro Feature
- Today
- Total
baegteun - iOS
Tuist 4 버전 업그레이드 본문
24년 2월 8일, Tuist 4.0.0이 공식적으로 릴리즈되었습니다.
Tuist가 4.0.0 Major 버전이 업그레이드되면서 변경된 점을 알아보겠습니다.
tuistenv를 통한 버전 관리 Drop
Tuist 4 이전에는 tuist install
tuist uninstall
등의 명령어를 통해 로컬에 있는 Tuist의 버전을 변경하거나, .tuist-version
파일에 버전을 정의해놓아서 프로젝트에서 사용할 Tuist 버전을 고정해놓아서 사용할 수 있었습니다. 그리고 이런 기능을 제공하는 것이 tuistenv
라는 도구였습니다. (tuist 설치 시 같이 설치되었습니다.)
하지만 tuistenv는 Tuist 4에는 완전히 삭제가 되었습니다.
Tuist 4로 업그레이드했다면 기존의 tuistenv는 curl-Ls https://uninstall.tuist.io | bash
로 제거하고 Mise를 사용하기를 적극적으로 권장한다고 하네요.
혹은 Homebrew 또한 지원한다고 합니다.
ProjectDescription 모델들의 init 생성자 Drop
Target, Scheme과 같은 ProjectDescription 모델들의 init 생성자를 제거합니다.
대신 static constructor를 통해 인스턴스 생성을 할 수 있도록 제공한다고 합니다.
생성자 API의 가독성과 표현력을 개선하기 위해 static constructor로 변경하게 되었다고 하네요.
e.g.
Target(name: ...)
->
Target.target(name: ...)
static constructor는 모델 이름을 사용하여 작명합니다.
e.g.
Target.target(…)
Arguments.arguments(…)
Path.path(…)
--no-cache 가 --no-binary-cache로 rename
tuist generate
tuist build
등의 명령어에서 사용할 수 있었던 --no-cache argument가 --no-binary-cache로 rename되었습니다.
--no-cache의 flag가 명확하지 않아 binary로 rename되었다고 합니다.
tuist fetch 가 tuist install 로 rename
의존성을 가져오는 명령어였던 tuist fetch가 tuist install로 rename되었습니다.
tuist와 결이 비슷한 툴과의 컨벤션을 맞추기 위함이라고 합니다.
npm install, yarn install 같은 이런 툴들을 말하는거같네요.
의존성 정의 방식을 Package.swift를 통한 방식으로 변경
Package.swift 파일 위치 - https://github.com/tuist/tuist/pull/5862
Package.swift 지원 - https://github.com/tuist/tuist/pull/5503
Tuist 4 이전에는 Tuist/Dependencies.swift 에서 혹은 프로젝트의 packages에 package를 추가해주어서 (Native SPM방식 사용) 서드파티 의존성을 가져올 수 있었으나 Dependencies.swift를 완전히 제거했습니다.
그 이유는 Dependabot, Renovatebot같은 툴을 사용할 수 없었고 사용자에게 불필요한 간접 참조?를 제공했기 때문이라네요.
새로운 방식으로는 Package.swift에 의존성을 정의해야합니다.
Package.swift의 경로는 Tuist/Package.swift가 아닌 프로젝트의 루트에 위치해야한다고 합니다.
사실 Package.swift를 통한 의존성을 정의하는 방식은 3.31.0부터 지원을 했습니다. 3버전 후반에는 Dependencies.swift는 deprecated처리만 되고 4버전부터는 사용이 완전히 불가능하게 되었습니다.
Dependencies.swift에서 할 수 있었던 의존성의 productType을 바꾸거나 사용 platform을 지정하는 설정은 #if TUIST 안에서 정의해야한다고 합니다.
자세한건 이 문서에서 확인할 수 있습니다.
// swift-tools-version: 5.8
import PackageDescription
#if TUIST
import ProjectDescription
import ProjectDescriptionHelpers
let packageSettings = PackageSettings(
productTypes: [
"Alamofire": .framework, // default is .staticFramework
],
platforms: [.iOS]
)
#endif
let package = Package(
name: "PackageName",
dependencies: [
.package(url: "https://github.com/Alamofire/Alamofire", from: "5.0.0"),
]
)
tuist cache warm이 tuist cache로 rename
tuist cache warm가 tuist cache로 더 짧게 사용할 수 있게 되었습니다.
tuist cache print-hashes가 tuist cache --print-hashes로 rename
print-hashes가 cache캐시 명령어의 플래그임을 명확히 하기 위해 tuist cache --print-hashes로 rename된다고 합니다.
Caching Profile 제거
Tuist 4 이전에는 Config.swift에서 cache의 profile을 지정할 수 있었습니다.
보통 debug, release의 configuration별로 profile을 분리해서 각각 cache이 적용되도록 하는 느낌으로 사용되는거같네요.
이 cache profile이 제거된다고 합니다.
제거하기로 한 이유는 프로젝트 생성 과정 중 생성에 사용된 프로필이 아닌 다른 프로필을 사용할 때 혼동을 일으킬 수 있다고 합니다.
또한 사용자가 debug 프로필로 릴리즈 버전을 빌드할 때 예상할 수 없는 결과가 발생할 수 있어서 제거한다고 합니다.
대신 cache 명령어의 옵션에--configuration를 추가하여 프로젝트를 생성할 때 configuration을 지정할 수 있게 되었습니다.
--skip-cache 제거
tuist generate
를 할 때 --skip-cache와 대상을 지정해서 캐시를 건너뛸 대상을 지정할 수 있었습니다.
하지만 Tuist 4 부터는 tuist generate Foo
와 같이 argument로 명시하는 대상이 캐시 스킵 대상으로 지정됩니다.
Signing Capabilities 기능 Drop
Tuist 3 버전대에서는 Tuist/Signing 디렉토리에 인증서와 프로비저닝 프로필을 넣어놓으면 tuist generate를 할 때 자동으로 Signing이 되는 기능을 제공해주었습니다.
하지만 Tuist 4 에서는 이 기능이 Drop되었습니다.
이유는 Fastlane이나 Xcode 자체 기능같이 커뮤니티 툴이 위 문제를 더 잘 해결하고 있기 때문입니다.
Signing은 Tuist의 장기적인 목표이기에 핵심 기능에 집중하는 것이 낫다고 생각하여 Drop했다고 합니다.
Dependencies.swift(Package.swift)를 통한 Carthage 지원 중단
Tuist 4 이전에는 Dependencies.swift에서 Carthage를 통한 의존성을 정의하고 가져올 수 있었지만 Tuist 4 부터는 직접적으로 Tuist를 통한 관리는 되지 않습니다.
* Carthage 사용이 불가능한게 아닙니다.
이유는 SPM이 의존성 관리 방법으로 선호될 미래를 고려할 때 Carthage는 장기적인 목표라고 생각하여 Drop했다고 합니다.
Carthage를 사용하기 위해서는 Carthage를 직접 사용하여 framework와 xcframework를 가져온 다음 TargetDependency.framework 또는 TargetDependency.xcframework로 바이너리를 참조해야한다고 합니다.
자세한건 이 문서에서 알아보실 수 있습니다.
Carthage만이 아닌 Cocoapods를 사용하여 서드파티 의존성을 가져올 수 있는 방법도 알려주네요.
TargetDependency.packagePlugin API Drop
https://github.com/tuist/tuist/pull/5555
https://github.com/tuist/tuist/pull/5719
Tuist 4 이전에는 TargetDependency.packagePlugin을 통해 패키지 플러그인을 의존성으로 정의할 수 있었지만 SPM이 새로운 패키지 유형을 도입한 것을 보고 유연하고 미래에 대비할 수 있는 방향으로 API를 변경했습니다.
TargetDependency.packagePlugin을 사용하고 있었다면 TargetDependency.package를 사용하고 argument에 패키지 타입을 전달하면된다고 합니다.
e.g.
TargetDependency.package(product: ..., type: .plugin)
TargetDependency.package(product: ..., type: .macro)
여기서 새로운 패키지 유형은 PR을 봤을 때 macro인듯하네요.
deprecated API Drop
deprecate 처리 된 API들이 삭제되었습니다.
예를들어 DeploymentTarget
이 Destinations
, DeploymentTargets
로 분리되며 deprecate된 DeploymentTarget
이 삭제된게 있겠네요.
References By
'Tuist' 카테고리의 다른 글
Tuist - Modular Architecture 개선하기 (4) | 2023.05.01 |
---|---|
Tuist 사용법 - 9. Micro Feature, uFeature(The Modular Architecture, TMA)로 확장성 높이기 (0) | 2023.04.03 |
Tuist 사용법 - 8. Scaffold, Template를 사용하여 새로운 모듈 만들기 (0) | 2023.02.15 |
Tuist 모듈화하기 - Modular Architecture 설계하기 (0) | 2023.01.05 |
Tuist 사용법 - 7. Configuration + XCConfig (11) | 2022.12.27 |