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
250
ライブラリをパブリッシュせずにすばやく試す
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
160
terraform-provider-aws にプルリクして マージされるまで
exoego
2
380
esbuild 最適化芸人
exoego
3
1.8k
いい感じに AWS を組み合わせたビルディングブロックでアプリ開発を支援する / TdTechTalk 2022 11
exoego
0
670
Empowering App Dev by Nicely-Crafted High-Level AWS Components
exoego
0
59
月間数十億リクエストのマイクロサービスを支える JVM+AWS フルサーバーレス開発事例 / Now and Future of Fully Serverless development at Chatwork
exoego
1
720
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
2k
Other Decks in Programming
See All in Programming
若手バックエンドエンジニアが Elasticsearch を使ってみた話
hott0mott0
1
100
Boos Performance and Developer Productivity with Jakarta EE 11
ivargrimstad
0
800
推しメソッドsource_locationのしくみを探る - はじめてRubyのコードを読んでみた
nobu09
2
370
Jakarta EE meets AI
ivargrimstad
0
850
.NET Frameworkでも汎用ホストが使いたい!
tomokusaba
0
220
Learning Kotlin with detekt
inouehi
1
220
[JAWS DAYS 2025] 最近の DB の競合解決の仕組みが分かった気になってみた
maroon1st
0
200
クリーンアーキテクチャから見る依存の向きの大切さ
shimabox
5
1.2k
フロントエンドオブザーバビリティ on Google Cloud
yunosukey
0
110
TCAを用いたAmebaのリアーキテクチャ
dazy
0
240
高セキュリティ・高耐障害性・サブシステム化。そして2億円
tasukulab280
2
380
【AI 自走型】Figma からデザインコーディングを行うプロンプト
tetsuro_b
0
110
Featured
See All Featured
The World Runs on Bad Software
bkeepers
PRO
67
11k
The Cost Of JavaScript in 2023
addyosmani
47
7.5k
The Art of Delivering Value - GDevCon NA Keynote
reverentgeek
11
1.3k
Art, The Web, and Tiny UX
lynnandtonic
298
20k
Optimizing for Happiness
mojombo
377
70k
Designing Dashboards & Data Visualisations in Web Apps
destraynor
231
53k
The Success of Rails: Ensuring Growth for the Next 100 Years
eileencodes
44
7.1k
A Tale of Four Properties
chriscoyier
158
23k
Fontdeck: Realign not Redesign
paulrobertlloyd
83
5.4k
The Illustrated Children's Guide to Kubernetes
chrisshort
48
49k
RailsConf 2023
tenderlove
29
1k
個人開発の失敗を避けるイケてる考え方 / tips for indie hackers
panda_program
100
18k
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