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
69
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
ビット演算の話 / Let's play with bit operations
kaityo256
PRO
4
170
2024-10-02 dev2next - Application Observability like you've never heard before
jonatan_ivanov
0
180
Re:PandasAI:生成AIがデータ分析業務にもたらすパラダイムシフト【増補改訂版】
negi111111
1
910
Интеграционное тестирование: как приручить хаос
lamodatech
0
560
"noncopyable types" の使いどころについて考えてみた
andpad
0
150
Real-time message handling and notifications with API Platform and Symfony
alli83
1
110
AWS CDKを用いたセキュアなCI/CDパイプラインの構築 / Build a secure CI/CD pipeline using AWS CDK
seike460
PRO
3
610
A Journey of Contribution and Collaboration in Open Source
ivargrimstad
0
450
◯◯エンジニアになった理由
gessy0129
PRO
0
650
コードレビューと私の過去と未来
jxmtst
0
270
Cloud Adoption Framework にみる組織とクラウド導入戦略
tomokusaba
2
460
What is TDD?
urakawa_jinsei
1
220
Featured
See All Featured
No one is an island. Learnings from fostering a developers community.
thoeni
19
2.9k
Designing Experiences People Love
moore
138
23k
Responsive Adventures: Dirty Tricks From The Dark Corners of Front-End
smashingmag
249
21k
Building Your Own Lightsaber
phodgson
102
6k
The Psychology of Web Performance [Beyond Tellerrand 2023]
tammyeverts
39
2.1k
Statistics for Hackers
jakevdp
796
220k
I Don’t Have Time: Getting Over the Fear to Launch Your Podcast
jcasabona
27
1.9k
Practical Orchestrator
shlominoach
186
10k
Raft: Consensus for Rubyists
vanstee
136
6.6k
What the flash - Photography Introduction
edds
67
11k
CSS Pre-Processors: Stylus, Less & Sass
bermonpainter
355
29k
Helping Users Find Their Own Way: Creating Modern Search Experiences
danielanewman
29
2.2k
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