[feat] lazy build on demand
まだ誰も着手していません。
評価
- 難易度
- 5/5
- 見積もり時間
- 1週間以上
- 初心者へのやさしさ
- 25/100
- issue の種類
- 機能追加
- 明瞭さ
- おおむね明確
- 活発さ
- 停滞
- 技術スタック
- typescript
- 領域
- backend, build-system, devops, security
調査の方向性
この issue には、repository のファイル、テスト、エントリーポイントが記載されていません。まず既存の registry request と build/publish flow を追跡し、次に package scripts、workflows、shallow repository fetches、caching、access checks をどのように組み合わせられるかを確認します。完了とは、要求された commit を一度だけビルドし、待機中のリクエストと共有して、安全に返せる状態を指します。
索引モデルが issue の本文から書いたものです。
説明
Eagerly building and publishing each commit to a registry can be demanding and requires active participation by the repo hosting the package (adding a workflow, configuration etc)
What if it was possible to do npm install vite@tbd --registry=https://pkg.pr.new or "vite":"https://pkg.pr.new/vite/tbd" instead? where tbd is a name scheme that tells the registry which commit exactly.
In the implementation, the first time someone requests a version, it would fetch the repo info from the public registry, then shallow fetch that commit, build and publish and then return the package. As soon as it is being built, other requests would wait for the first to finish. After it is published, it doesn't have to be built again.
Advantages
- only packages that get requested are built/stored
- implementing eviction after X days without a request + LRU gives you more control over max resource used.
- in monorepos with
workspace:references you can easily use these lazy build references to resolve them
Possible issues
How do you know the calls needed to build the package, esp if they can change over time?
Idea: by default, look for build/publish scripts, just call them (for publish override the registry with your custom). If that doesn't work/exist, check workflows for release/publish.yml and again override the registry. Last resort is a configuration for that package in its own repo or here
How to secure it?
To prevent someone creating a malicious fork and then promoting the on-demand url it should be possible to block on a repo basis or and/or check for workflow run permission on the PR of that fork in the origin repo (not sure if thats possible via gh api)
- 主要言語
- TypeScript
- スター
- 1.9k
- フォーク
- 131
- 平均マージ
- 1日 12時間
- マージ済み PR（30日）
- 6
環境構築
このプロジェクトには開発コンテナ、Dockerfile、コントリビューションガイドがありません。まず README を読み、一般的な手順ははじめてのコントリビューションガイドを参照してください。
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
stackblitz-labs/pkg.pr.new のほかの issue
-
A preview build is labelled with the head sha but built from the merge ref, and nothing says soオープン
難易度 4/5 3〜5日 初心者へのやさしさ 52/100
stackblitz-labs/pkg.pr.new#557 · コメント 1 件 · リアクション 1 件 ·
-
難易度 4/5 3〜5日 初心者へのやさしさ 25/100
stackblitz-labs/pkg.pr.new#531 · コメント 2 件 ·
-
--template does not resolve pnpm catalog: references before uploading to StackBlitz対応中かも @kunalgoesbyken が 9 日前に担当しました。 オープン
難易度 3/5 1〜2日 初心者へのやさしさ 55/100
stackblitz-labs/pkg.pr.new#489 · コメント 1 件 · リアクション 1 件 ·
-
難易度 5/5 1週間以上 初心者へのやさしさ 35/100
stackblitz-labs/pkg.pr.new#482 · リアクション 1 件 ·
-
難易度 4/5 3〜5日 初心者へのやさしさ 35/100
stackblitz-labs/pkg.pr.new#343 · コメント 1 件 ·
stackblitz-labs/pkg.pr.new の issue をすべて見る
似ている issue
-
難易度 2/5 1〜3時間 初心者へのやさしさ 84/100
pingdotgg/t3code#30228 · コメント 2 件 ·
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
-
ci-cd desktop size:low telemetry-improvement telemetry-round-1
難易度 2/5 1〜3時間 初心者へのやさしさ 66/100
vfarcic/dot-agent-deck#2079 ·
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 75/100
メンテナーはふだん 1 日以内に返信
-
難易度 1/5 1時間未満 初心者へのやさしさ 83/100
メンテナーはふだん 1 日以内に返信