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
140
ライブラリをパブリッシュせずにすばやく試す
2024.5.24
Nextbeat tech bar 第1回
TATSUNO Yasuhiro
May 24, 2024
Tweet
Share
More Decks by TATSUNO Yasuhiro
See All by TATSUNO Yasuhiro
esbuild 最適化芸人
exoego
3
1.1k
いい感じに AWS を組み合わせたビルディングブロックでアプリ開発を支援する / TdTechTalk 2022 11
exoego
0
480
Empowering App Dev by Nicely-Crafted High-Level AWS Components
exoego
0
20
月間数十億リクエストのマイクロサービスを支える JVM+AWS フルサーバーレス開発事例 / Now and Future of Fully Serverless development at Chatwork
exoego
1
590
Scala と AWS でフルサーバーレス開発事例 / How Chatworks uses Scala and Serverless
exoego
3
1.3k
忙しい Scala 開発者の超時間節約術 / Big Timesavers for Busy Scala Developers
exoego
1
1k
TypeScript の便利な型変形を なんとかして Scala.js で使う / Emulating TypeScript Utility Types in ScalaJS
exoego
2
1.8k
Lintでレビューをラクにしよう/ Easing Code Review with Lint for TypeScript
exoego
3
500
AIのビジネス利用を加速する教師データ作成の戦略 / Annotation Strategy to accelerate using AI for business
exoego
0
1.2k
Other Decks in Programming
See All in Programming
Kotlin Collection関数をマスター
masayukisuda
0
1.3k
ChecksでアプリコンプライアンスとAIの安全性をシンプルに - セッション紹介
takakitojo
0
160
Android アプリのプロジェクトをモダンにし続ける工夫
numeroanddev
1
380
ぎゃるえんじにあがハッカソンの虜になった!
rino7_tech
1
250
Google I/O 2024 Android 開発ツールの新機能
tonionagauzzi
0
170
技術カンファレンスをより楽しむためにやるべき N 個のこと / N Things You Should Do to Enjoy Tech Conferences More
mackey0225
3
260
チームの成長を促すためのスプリントレトロスペクティブの活用法 / How to use sprint retrospectives to promote team growth
mackey0225
4
540
スクラムチームに入れないという選択: フルサイクルチームにおける開発者のステップアップ / Why We Don’t Add Newbies to Our Scrum Team
yuk4w4
2
1.2k
過去や未来を扱うのは難しい? 過去と未来に立ち向かうための勘所
shinpeim
2
340
生成AIキャラクター作成プラットフォームにおける LLM応答の柔軟性の拡張の工夫
ykimura517
3
830
Kotlin/Androidでテスト駆動開発をはじめよう
hiroaki404
0
120
エンジニアが開発生産性を上げるためにやる最初の一歩
ktchiroyah
0
110
Featured
See All Featured
Building Your Own Lightsaber
phodgson
101
5.8k
Designing with Data
zakiwarfel
96
4.9k
Side Projects
sachag
451
41k
WebSockets: Embracing the real-time Web
robhawkes
59
7.1k
Designing on Purpose - Digital PM Summit 2013
jponch
112
6.6k
Adopting Sorbet at Scale
ufuk
69
8.7k
What's in a price? How to price your products and services
michaelherold
238
11k
個人開発の失敗を避けるイケてる考え方 / tips for indie hackers
panda_program
73
15k
The Cost Of JavaScript in 2023
addyosmani
25
4.1k
GitHub's CSS Performance
jonrohan
1025
450k
Statistics for Hackers
jakevdp
791
220k
Docker and Python
trallard
36
2.8k
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