Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
ライブラリをパブリッシュせずにすばやく試す
Search
TATSUNO Yasuhiro
May 24, 2024
Programming
2
190
ライブラリをパブリッシュせずにすばやく試す
2024.5.24
Nextbeat tech bar 第1回
TATSUNO Yasuhiro
May 24, 2024
Tweet
Share
More Decks by TATSUNO Yasuhiro
See All by TATSUNO Yasuhiro
Bun に LCOV 出力を実装した
exoego
2
68
terraform-provider-aws にプルリクして マージされるまで
exoego
2
310
esbuild 最適化芸人
exoego
3
1.5k
いい感じに AWS を組み合わせたビルディングブロックでアプリ開発を支援する / TdTechTalk 2022 11
exoego
0
560
Empowering App Dev by Nicely-Crafted High-Level AWS Components
exoego
0
28
月間数十億リクエストのマイクロサービスを支える JVM+AWS フルサーバーレス開発事例 / Now and Future of Fully Serverless development at Chatwork
exoego
1
650
Scala と AWS でフルサーバーレス開発事例 / How Chatworks uses Scala and Serverless
exoego
3
1.4k
忙しい Scala 開発者の超時間節約術 / Big Timesavers for Busy Scala Developers
exoego
1
1.1k
TypeScript の便利な型変形を なんとかして Scala.js で使う / Emulating TypeScript Utility Types in ScalaJS
exoego
2
1.9k
Other Decks in Programming
See All in Programming
コードレビューと私の過去と未来
jxmtst
0
230
Compose Multiplatform과 Ktor로 플랫폼의 경계를 넘어보자
kwakeuijin
0
250
データサイエンスのフルサイクル開発を実現する機械学習パイプライン
xcnkx
2
490
Taking LLMs out of the black box: A practical guide to human-in-the-loop distillation
inesmontani
PRO
3
1.2k
ACES Meet におけるリリース作業改善の取り組み
fukucheee
0
130
AWS認定資格を受験するにあたり、気づいたこと・実践していたことのまとめ
satoshi256kbyte
1
120
Applied NLP in the Age of Generative AI
inesmontani
PRO
3
1.2k
Micro Frontends for Java Microservices - dev2next 2024
mraible
PRO
0
200
モジュラモノリス、その前に / Modular monolith, before that
euglena1215
6
660
Cohesion in Modeling and Design
mploed
3
190
型付きで行うVSCode拡張機能開発 / VSCode Meetup #31
mazrean
0
230
全方位強化 Python 服務可觀測性:以 FastAPI 和 Grafana Stack 為例
blueswen
1
370
Featured
See All Featured
Exploring the Power of Turbo Streams & Action Cable | RailsConf2023
kevinliebholz
26
4k
Rails Girls Zürich Keynote
gr2m
93
13k
The Power of CSS Pseudo Elements
geoffreycrofte
71
5.3k
"I'm Feeling Lucky" - Building Great Search Experiences for Today's Users (#IAC19)
danielanewman
225
22k
Building a Modern Day E-commerce SEO Strategy
aleyda
38
6.8k
Making the Leap to Tech Lead
cromwellryan
130
8.8k
Building Adaptive Systems
keathley
37
2.1k
Become a Pro
speakerdeck
PRO
24
4.9k
Statistics for Hackers
jakevdp
796
220k
Distributed Sagas: A Protocol for Coordinating Microservices
caitiem20
327
21k
The Invisible Side of Design
smashingmag
297
50k
個人開発の失敗を避けるイケてる考え方 / tips for indie hackers
panda_program
92
16k
Transcript
2024.5.23 nagoya.ts #1 TATSUNO Yasuhiro 2024.5.24 Nextbeat Tech Bar 第1回
TATSUNO Yasuhiro esbuild 最適化芸人 ライブラリを パブリッシュせずに すばやく試す
👍
2024.5.23 nagoya.ts #1 TATSUNO Yasuhiro 「こんな小さな題材でいいなら 自分も発表できるかも」 と呼水になるような小さな話
ライブラリ開発でよく困ること① OSS がなかなか対応してくれない問題 - こんなことってありますよね - すぐ使いたい修正のプルリクを送ったけど、ぜんぜんマージされない…… - マージはされたけど、ぜんぜんパブリッシュされない……スナップショット版もない…… 👹🪓「fork
すればいいのでは。仕事で必要ならそれくらいやるべき」 - はい……。でも fork って敷居高いこともありますよね - JVM 系 Sonatype OSS Hosting はパブリッシュ先を開く手続きが大変 - GitHub や JFrog などの private repository? みんながみんな使えるわけじゃない - fork したライブラリを使ってる下流ライブラリの修正は? すべて fork はとても現実的でない - OSS がパブリッシュされるまでの数日〜数週間をラクにしのぎたいんじゃ〜
ライブラリ開発でよく困ること② 実際に使ってみて手戻りするとだるい問題 - こんなことってありますよね - 言語機能や依存ライブラリを誤解してたりして、欲しかった動作と違うわ…… - これはこれでいいが、こっちのケースのためのオプション欲しいわ…… - 手戻りに時間とられちゃう
- 自作ライブラリの場合、単純にパブリッシュ作業だるい(自動化もだるい……) - なかなか対応してくれない OSS の場合、ま〜た待たされてしまう - 結果、ライブラリ開発やライブラリ更新を先送りしがち…… - パブリッシュとかしないで試してすぐ直したいんじゃ〜
2024.5.23 nagoya.ts #1 TATSUNO Yasuhiro esbuild 最適化芸人 maven central とか
npm とか pypi とか rubygems とかに パブリッシュしないで 使えたらな〜
2024.5.23 nagoya.ts #1 TATSUNO Yasuhiro できる!! 知ってしまえば当たり前でも 知らずに損してる人はきっと大勢いる
①ローカルにあるライブラリを使う 場面:全世界や社内に面倒なパブリッシュする前に、PC上でいくつかのレポジトリ で変更したライブラリを試したい 注意:あくまでも自分のPCに閉じたものなので、CI で(カンタンには) 動かせない gradle (Java/Kotlin) sbt (Scala)
npm (Node.js) publishToMavenLocal して 利用側でそのバージョン指定 publishLocal して 利用側でそのバージョン指定 利用側 package.json で “mylib”: “file:../path/to/lib” go.mod? (Go) Rust cargo bundler (Ruby) 利用側 go.mod で replace でパス指定 require foo.com/mylib v0.0.1 replace foo.com/mylib v0.0.1 => path/to/lib 利用側 Cargo.toml で mylib = { path=“path/to/lib” } 利用側 Gemfile で gem ‘mylib’, path: ‘path/to/lib` あくまで自分で使ったことあるやつだけです。載ってないやつはググってね〜
② git レポジトリにあるライブラリを使う 場面:snapshot 版もない OSS のパブリッシュを待つ間などに、先行して使いだし たい。なので、CI/CD でもライブラリが使える必要がある 注意:予期せぬ変更がないように、頻繁に変わる
”main” ブランチなどではなく、 feature branch、tag、または commit hash を指定するのが望ましい gradle (Java/Kotlin) sbt (Scala) npm (Node.js) ❌ できない(はず…) ❌ できない(はず…) 利用側 package.json で “mylib”: “github:owner/repo#branch” または “mylib”: “git://example.com/repo#branch” go.mod? (Go) cargo (Rust) bundler (Ruby) Git、SVN などの構成管理システムからライブ ラリを取得するのが基本。特別な指定は不要 require foo.com/mylib next 利用側 Cargo.toml で mylib = { git=“https://github.com/…”, branch=”next” } 利用側 Gemfile で gem ‘mylib’, git: ‘https://github.com/…`, branch: ‘next’ あくまで自分で使ったことあるやつだけです。載ってないやつはググってね〜 ライブラリ開発者側がバイトコードにコンパイルして1度パブリッシュすれば 利用者側でコンパイル不要で使える、という普段はいい仕組みが裏目に(?)
まとめ - ライブラリ開発や利用をちょっと助ける小さな話を LT しました - ライブラリのローカル版は、手元ですばやくトライアンドエラーに使える - ライブラリの Git
レポジトリ版は、CI/CD でも利用できるので、実際の運用 に使える。OSS のパブリッシュを待つ一時しのぎになる
ぼくとライブラリ開発 最近自分で作ってるやつ(いずれも GitHub) - exoego/rspec-openapi k0kubun さんから継承 - exoego/esbuild-bundle-analyzer -
exoego/cold-stat 最近プルリク送ってるやつ - terraform-aws-provider - tfaction - scala-steward-action - aws.permission.cloud - hono - markuplint