Do you also have a package.json file in your project?

I tried reproducing the problem and with provided deno.json and running deno add npm:debug I don't get any error. @silverbucket could you please provide more information about your project?

@bartlomieju Sure what would you like to see? To answer your question, there is no package.json.

$ ls -al
total 40
drwxr-xr-x@  9 njenning  staff   288 Oct 31 01:26 .
drwxr-xr-x@ 15 njenning  staff   480 Aug 26 23:06 ..
-rw-r--r--@  1 njenning  staff  1077 Aug 26 23:06 LICENSE
-rw-r--r--@  1 njenning  staff   271 Aug 29 14:54 README.md
drwxr-xr-x@  2 njenning  staff    64 Oct 31 01:24 coverage
-rw-r--r--@  1 njenning  staff   823 Oct 31 01:26 deno.json
-rw-r--r--@  1 njenning  staff  5814 Aug 27 17:53 deno.lock
drwxr-xr-x@  4 njenning  staff   128 Aug 27 17:44 scripts
drwxr-xr-x@ 12 njenning  staff   384 Oct 31 01:23 src

$ deno add npm:debug
Add npm:[email protected]
error: Failed to install from package.json

Caused by:
    0: Invalid version requirement
    1: Unexpected character.
         ^
         ~

It might be worth mentioning that this is a mono-repo, however I've never had issues converting packages one at a time with deno 1.45, it was only upgrading to 2.0.x that I started getting issues like this.

@silverbucket is your reo public so o could try it myself?

We should improve this error message to say the file the error occurs in. Probably there's a package.json in the workspace in this case.

@bartlomieju Here's the repo + branch + package in the mono repo where I ran those commands: https://github.com/sockethub/sockethub/tree/migrate-to-deno/packages/schemas

But while I was checking the modified files to commit and update that branch before I wrote this message, I noticed that the root package.json was modified with the debug dependencies. This goes along with what @dsherret was suggesting.

So, for some reason, using deno add while being in the packages/schemas/ directory (which has it's own deno.json file), deno is decided to try to add those to the repository root package.json and getting a syntax error of some sort (I still don't know what the syntax error is referring to as it's rather obtuse).

diff --git a/package.json b/package.json
index b805b00b..257b9dae 100644
--- a/package.json
+++ b/package.json
@@ -4,6 +4,9 @@
   "engines": {
     "deno": ">=1.45"
   },
+  "dependencies": {
+    "debug": "^4.3.7"
+  },
   "devDependencies": {
     "@sockethub/data-layer": "workspace:1.0.0-alpha.4",
     "@sockethub/schemas": "workspace:3.0.0-alpha.4",

I opened #26665 which should help reduce the confusion slightly in the future. It will say the package.json file and the dependency that caused the issue.

So, for some reason, using deno add while being in the packages/schemas/ directory (which has it's own deno.json file), deno is decided to try to add those to the repository root package.json and getting a syntax error of some sort (I still don't know what the syntax error is referring to as it's rather obtuse).

@nathanwhit could you take a look? I don't think it should be doing that.

Deno prefers to add npm dependencies to package.json file over deno.json, but yeah it's a bug - it should only happen for package.json in the same directory as deno.json, it shouldn't walk up the file tree to find package.json.

Using deno 2.0.6 I'm getting another variation of this bug. Same repo I mentioned about, this time it's not with the package.json at the root of the repository, but a different pacakge at the same level as the schemas package.

project-root/packages/schemas $ deno install
error: Failed to install '@sockethub/client'
    at file:///project-root/packages/examples/package.json

Caused by:
    0: Invalid version requirement
    1: Unexpected character.
         ^
         ~

@nathanwhit Should I create a new ticket? Or can you re-open this one?

Hmm we're putting the dependency in the correct file now, but we error out because we validate all of the package.json files in the workspace when we cache the dependencies, and one of them has a version requirement (workspace:^) that we don't support.

I feel like maybe we should make workspace:^ not a hard error?

@nathanwhit we should just support it, see #26726