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
220
ライブラリをパブリッシュせずにすばやく試す
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
94
terraform-provider-aws にプルリクして マージされるまで
exoego
2
350
esbuild 最適化芸人
exoego
3
1.7k
いい感じに AWS を組み合わせたビルディングブロックでアプリ開発を支援する / TdTechTalk 2022 11
exoego
0
610
Empowering App Dev by Nicely-Crafted High-Level AWS Components
exoego
0
38
月間数十億リクエストのマイクロサービスを支える JVM+AWS フルサーバーレス開発事例 / Now and Future of Fully Serverless development at Chatwork
exoego
1
680
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
The Efficiency Paradox and How to Save Yourself and the World
hollycummins
1
450
return文におけるstd::moveについて
onihusube
1
1.1k
Итераторы в Go 1.23: зачем они нужны, как использовать, и насколько они быстрые?
lamodatech
0
790
見えないメモリを観測する: PHP 8.4 `pg_result_memory_size()` とSQL結果のメモリ管理
kentaroutakeda
0
370
アクターシステムに頼らずEvent Sourcingする方法について
j5ik2o
4
280
各クラウドサービスにおける.NETの対応と見解
ymd65536
0
100
php-conference-japan-2024
tasuku43
0
310
20年もののレガシープロダクトに 0からPHPStanを入れるまで / phpcon2024
hirobe1999
0
490
useSyncExternalStoreを使いまくる
ssssota
6
1.1k
「Chatwork」Android版アプリを 支える単体テストの現在
okuzawats
0
180
良いユニットテストを書こう
mototakatsu
8
2.5k
テストケースの名前はどうつけるべきか?
orgachem
PRO
0
140
Featured
See All Featured
The Cult of Friendly URLs
andyhume
78
6.1k
How to Think Like a Performance Engineer
csswizardry
22
1.2k
Scaling GitHub
holman
458
140k
Unsuck your backbone
ammeep
669
57k
Stop Working from a Prison Cell
hatefulcrawdad
267
20k
Save Time (by Creating Custom Rails Generators)
garrettdimon
PRO
28
900
A Philosophy of Restraint
colly
203
16k
Visualization
eitanlees
146
15k
Dealing with People You Can't Stand - Big Design 2015
cassininazir
365
25k
The Pragmatic Product Professional
lauravandoore
32
6.3k
Typedesign – Prime Four
hannesfritz
40
2.4k
Making Projects Easy
brettharned
116
5.9k
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