[feat] lazy build on demand
Chưa có ai nhận issue này.
Đánh giá
- Độ khó
- 5/5
- Thời gian dự kiến
- Hơn một tuần
- Mức phù hợp với người mới
- 25/100
- Loại issue
- Tính năng
- Độ rõ ràng
- Khá rõ ràng
- Mức độ hoạt động
- Đình trệ
- Công nghệ
- typescript
- Lĩnh vực
- backend, build-system, devops, security
Hướng nghiên cứu
Issue không nêu tên tệp repository, test hay entry point nào. Hãy bắt đầu bằng cách lần theo registry request và build/publish flow hiện có, sau đó xem xét package scripts, workflows, shallow repository fetches, caching và access checks có thể kết hợp như thế nào; công việc được xem là hoàn tất khi một commit được yêu cầu có thể được build một lần, chia sẻ với các request đang chờ và trả về một cách an toàn.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
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)
- Ngôn ngữ chính
- TypeScript
- Star
- 1.9k
- Fork
- 131
- Merge trung bình
- 1 ngày 9 giờ
- Pull request đã merge (30 ngày)
- 6
Chuẩn bị môi trường
Dự án này không cung cấp dev container, Dockerfile hay hướng dẫn đóng góp, nên bạn cần tự thiết lập môi trường: hãy bắt đầu từ README và xem hướng dẫn đóng góp lần đầu của chúng tôi để biết các bước chung.
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của stackblitz-labs/pkg.pr.new
-
A preview build is labelled with the head sha but built from the merge ref, and nothing says soĐang mở
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 52/100
stackblitz-labs/pkg.pr.new#557 · 1 bình luận · 1 reaction ·
-
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 25/100
stackblitz-labs/pkg.pr.new#531 · 2 bình luận ·
-
--template does not resolve pnpm catalog: references before uploading to StackBlitzCó thể đã có người làm @kunalgoesbyken đã nhận 6 ngày trước. Đang mở
Độ khó 3/5 1-2 ngày Mức phù hợp với người mới 55/100
stackblitz-labs/pkg.pr.new#489 · 1 bình luận · 1 reaction ·
-
Độ khó 5/5 Hơn một tuần Mức phù hợp với người mới 35/100
stackblitz-labs/pkg.pr.new#482 · 1 reaction ·
-
Abstract CLI From FunctionalityĐang mở
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 35/100
stackblitz-labs/pkg.pr.new#343 · 1 bình luận ·
Tất cả issue của stackblitz-labs/pkg.pr.new
Issue tương tự
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 76/100
Northeastern-Electric-Racing/FinishLine#4660 ·
Maintainer thường phản hồi trong vòng 2 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 86/100
excaliburjs/Excalibur#3895 ·
Maintainer thường phản hồi trong vòng 3 ngày
-
infer_audio_type only recognises one MPEG Layer III frame header, so most MP3 files are rejectedCó thể đã có người làm @Steve-20-ai đã nhận hôm nay. Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 78/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Earn report crashes with "RangeError: Invalid time value" when a report row has an unparsable timestampCó thể đã có người làm @Gurkaran18 đã nhận hôm nay. Đang mởbug
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 75/100
joinmarket-webui/jam#1588 ·
Maintainer thường phản hồi trong vòng 3 ngày
-
BeOS .json missingĐang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 72/100
mihaip/infinite-mac#475 ·