stackblitz-labs / stackblitz-labs/pkg.pr.new

[feat] lazy build on demand

Open
#98 3 comments 1 reaction 0 assignees View on GitHub

Nobody has claimed this yet.

enhancement
Dominant language
TypeScript
Stars
1.9k
Forks
127
PR merge metrics
No merged PRs in 30d

Description

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)

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

The issue names no repository files, tests, or entry points. Start by tracing the existing registry request and build/publish flow, then review how package scripts, workflows, shallow repository fetches, caching, and access checks could fit; done would mean a requested commit can be built once, shared with waiting requests, and returned securely.

Written by the indexing model from the issue text.

Assessment

Tech stack
typescript
Domain
backend, build-system, devops, security
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.