This is just: #22651

Let's track that there. Also, atm bare specifiers for npm packages aren't supported, but I think we should. Follow #24605 for that

Oh wait, that one is slightly different

I've focused this one to it not discovering the jsr.json of the folder (again, let's track the bare specifier for the npm package here: #24605).

I'm not sure we should do this outside of deno publish. It's yet another config file that we need to discover and will make things slower.

atm bare specifiers for npm packages aren't supported, but I think we should

Agreed. Or, if they're not supported, deno should throw an error/warning when trying to add such a package as a workspace member. Being able to add a thing to a workspace without it getting a name I can use to import it seems broken.

I've focused this one to it not discovering the jsr.json

I'm a bit worried that that's focusing on the solution, rather than the problem. The real problem is that workspaces are documented to work with package.json, I added a library with a package.json, and I got a workspace member that I can't refer to.

I don't mind whether it's fixed by honoring package.json or jsr.json. But I'd very much rather the solution not be "This pattern is unsupported in workspaces" because adding a third-party library as a workspace member (documented here) is a really handy way to work on fixing issues locally, so I'd really like that to work for most third-party libraries I might encounter in the wild. (Whether they use deps.ts, import map, or package.json npm dependencies.)

I'm a bit worried that that's focusing on the solution, rather than the problem. The real problem is that workspaces are documented to work with package.json, I added a library with a package.json, and I got a workspace member that I can't refer to.

That's what #24605 is. You should be able to refer to it with an npm specifier otherwise or by adding it as a dependency in a package.json (in a package.json, a matching dependency will work or you can use a workspace specifier).

Was brainstorming about this, and maybe this is a separate ticket for some point in the future, but it would be handy to say how a workspace member is "imported". For example, say I've got a project that uses an import map alias for a dependency:

"imports": {
    "foo": "jsr:@scope/the-great-foo-library"
}

All my code does import foo from "foo"

But now I need to fix that library locally using the pattern I linked to: cloning it locally, and adding it as a workspace member.

"workspace": ["./the_great_foo_library"]

But, now I have to use its declared name, instead of the alias I'm using throughout my codebase. And in the case where it has both jsr.io / package.json, maybe the way I import it doesn't match the (eventual) one that Deno picked to import in that case. Having a way for the workspace to declare the import name here would be handy.

ex, something like:

"workspace": {
    "./the_great_foo_libriary": {
        "importName": "foo",
    }

But now I need to fix that library locally...

We've been brainstorming this one and we're thinking maybe a separate mechanism for "patching packages" similar to cargo: https://doc.rust-lang.org/cargo/reference/overriding-dependencies.html -- we're going to open an issue soon.

That would handle scenarios like when you want to use a local version of a package, but that package is itself part of another workspace. We'll need a way to resolve with multiple workspaces in that case.