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)
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.newor"vite":"https://pkg.pr.new/vite/tbd"instead? wheretbdis 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
workspace:references you can easily use these lazy build references to resolve themPossible 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)