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

[inverted-capital]

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 team is currently the best positioned to define the way to do this, and is the reference way to manage a large workspace.

The problem specifically is that, to follow the conventions of the team is actually quite hard. The process is also hard coded to be for 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 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 has had to handle far more problems than we ever have.

[BlackAsLight]

Many of the things being done here can be done via the Deno binary alone.

• Create tests to validate functionality: Deno.test + deno test --trace-leaks --parallel
• Use the coverage command to see which lines aren't being tested: deno test --coverage --clean && deno coverage --html coverage/
• Check fmt, linting, and dry publishing: deno fmt --check && deno lint && deno publish --dry-run
• Check JSDoc examples work: deno test --doc

Many of these tests commands could be combined to save time. If you're supporting more than one runtime and want to validate the linting in others then you could make a second deno.json called something else "browser-compat.tsconfig" for example and run deno lint again.

Things that the std does that isn't available here are stuff like checking JSDocs meet a certain standard.

[inverted-capital]

Many of the things being done here can be done via the Deno binary alone.

Yes, but some of the things being done here are non trivial. Also guidance as to how to do them is value, too.

What I am proposing here, practically speaking, is that the tools folder be itself turned into a first class member of the standard library. The functionality in this folder is valuable to all package publishers, as well as those who publish from a workspace.

That functionality is primarily:

• checking browser compatibility
• checking node compatibility
• circular reference checking
• deprecation management
• docs linting
• license checking

Secondly, patterns, like how you release unstable features - that is quite good - the tools to do that should be here as well.

The last set of functions that I think should be added are package lifecycle management:

• add a new package
• deprecate a package
• remove a package
• rename a package

I know your goal is to keep the standard library compact - I just thought I would share a view from the outside looking in, trying to use your patterns and tools as the reference on how to publish a collection of packages to jsr.