Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

[feat] lazy build on demand

Đang mở
#98 3 bình luận 1 reaction 0 người được giao Xem trên GitHub

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

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ả

enhancement

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
  1. only packages that get requested are built/stored
  2. implementing eviction after X days without a request + LRU gives you more control over max resource used.
  3. 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

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. 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.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của stackblitz-labs/pkg.pr.new

Tất cả issue của stackblitz-labs/pkg.pr.new

Issue tương tự

Thêm issue về TypeScript

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.