denoland / denoland/std

make a @std/workspaces package and use it for your own management of @std

Open
#6,141 2 comments 1 reaction 0 assignees View on GitHub
Dominant language
TypeScript
Stars
3.6k
Forks
681
PR merge metrics
No merged PRs in 30d

Description

Thank you for the standard library - the value of the solution each component provides for so many people cannot be recognized enough.

The new problem it presents is:

> [!IMPORTANT]
> **what is the canonical way to manage a large deno `workspace` project that publishes to jsr ?**

The [![JSR @std](https://jsr.io/badges/@std)](https://jsr.io/@std) team is currently the best positioned to define the way to do this, and [![JSR @std](https://jsr.io/badges/@std)](https://jsr.io/@std) is the reference way to manage a large workspace.

The problem specifically is that, to follow the conventions of the [![JSR @std](https://jsr.io/badges/@std)](https://jsr.io/@std) team is actually quite hard. The process is also hard coded to be for [![JSR @std](https://jsr.io/badges/@std)](https://jsr.io/@std) versus being generally applicable.

May I suggest either a package that can handle this, or a template repository that we can use ? Preferably something that, when new best practices are decided upon, we just update our package and we inherit all that hard work ? What I am suggesting is that the practices employed in this repo be extracted out and genericized, so it gets used in the standard library as well as being reusable by others.

The current best alternative that we could find is to fork the [![JSR @std](https://jsr.io/badges/@std)](https://jsr.io/@std) repo, wipe out the bits we don't need, and hope that it isn't too hard to merge in upstream changes whenever the process for release is changed. We have started doing this in https://github.com/dreamcatcher-tech/napps but as you can see, it is a bit sloppy. The exact process appears to have some stale code as well, which decoyed our efforts slightly: #4673

As painful as copying was, it is still far better than building up our own process, since clearly [![JSR @std](https://jsr.io/badges/@std)](https://jsr.io/@std) has had to handle far more problems than we ever have.

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.