Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SyntaxError: Unexpected end of JSON input when trying to publish packages #397

Closed
talentlessguy opened this issue Jun 20, 2020 · 51 comments Β· Fixed by #676
Closed

SyntaxError: Unexpected end of JSON input when trying to publish packages #397

talentlessguy opened this issue Jun 20, 2020 · 51 comments Β· Fixed by #676
Labels
bug Something isn't working

Comments

@talentlessguy
Copy link
Contributor

talentlessguy commented Jun 20, 2020

Affected Packages

All of the packages

Problem

When I try to publish my packages using pnpx changesets publish I get this error:

➜ pnpx changeset publish
πŸ¦‹  info npm info @tinyhttp/app
πŸ¦‹  info npm info @tinyhttp/cors
πŸ¦‹  info npm info @tinyhttp/etag
πŸ¦‹  info npm info @tinyhttp/logger
πŸ¦‹  info npm info @tinyhttp/static
πŸ¦‹  info @tinyhttp/app is being published because our local version (0.1.21) has not been published on npm
πŸ¦‹  info @tinyhttp/cors is being published because our local version (0.1.20) has not been published on npm
πŸ¦‹  info @tinyhttp/etag is being published because our local version (0.1.20) has not been published on npm
πŸ¦‹  info @tinyhttp/logger is being published because our local version (0.1.20) has not been published on npm
πŸ¦‹  info @tinyhttp/static is being published because our local version (0.1.20) has not been published on npm
πŸ¦‹  info Publishing "@tinyhttp/app" at "0.1.21"
πŸ¦‹  info Publishing "@tinyhttp/cors" at "0.1.20"
πŸ¦‹  info Publishing "@tinyhttp/etag" at "0.1.20"
πŸ¦‹  info Publishing "@tinyhttp/logger" at "0.1.20"
πŸ¦‹  info Publishing "@tinyhttp/static" at "0.1.20"
πŸ¦‹  error SyntaxError: Unexpected end of JSON input
πŸ¦‹  error     at JSON.parse (<anonymous>)
πŸ¦‹  error     at internalPublish (/home/v1rtl/Coding/tinyhttp/node_modules/.pnpm/@changesets/cli@2.9.1_@types+node@14.0.13/node_modules/@changesets/cli/dist/cli.cjs.dev.js:591:19)
πŸ¦‹  error     at processTicksAndRejections (internal/process/task_queues.js:97:5)

Same happens with ./node_modules/.bin/changeset publish

I don't know what causes it because there's no clear error message.

Helpful info

reproduction repository: https://github.com/talentlessguy/tinyhttp
changesets config: https://github.com/talentlessguy/tinyhttp/blob/master/.changeset/config.json
node version: 14.4.0
pnpm version: 5.0.2
npm version: 6.14.5

@ifiokjr
Copy link

ifiokjr commented Jul 5, 2020

I'm having the exact same issue with pnpm

The failing build is here https://github.com/remirror/remirror/pull/251/checks?check_run_id=838235175
The commit causing the issue is here: https://github.com/remirror/remirror/tree/7f4153e0b08ae709dbdd28b09d6ebd3809e9a825
Config: https://github.com/remirror/remirror/blob/7f4153e0b08ae709dbdd28b09d6ebd3809e9a825/support/root/.changeset/config.json
Prerelease config: https://github.com/remirror/remirror/blob/7f4153e0b08ae709dbdd28b09d6ebd3809e9a825/support/root/.changeset/pre.json

Node: 12
pnpm: 5.2.6

The annoying thing is that I also can't run the release command from my own machine. It just freezes at the same point with no error displayed.

@Andarist
Copy link
Member

Andarist commented Jul 5, 2020

Thank you both for those reports. I will make sure to investigate this asap.

@Andarist Andarist added the bug Something isn't working label Jul 5, 2020
ifiokjr added a commit to remirror/remirror that referenced this issue Jul 5, 2020
@ifiokjr
Copy link

ifiokjr commented Jul 5, 2020

In order to get the release to work I've patched the @changesets/cli package to use npm for publishing always regardless of the project. The publish now works locally.

It's possible something changed in pnpm publish in version 5. Although this is the first time I've actually used pnpm to publish so I'm not sure.

@zkochan
Copy link
Contributor

zkochan commented Jul 5, 2020

@ifiokjr you may just use pnpm to publish the bumped versions. Just run pnpm publish -r.

@ifiokjr
Copy link

ifiokjr commented Jul 5, 2020

Ahh that's very useful to know. It looks like pnpm is using changesets as well. How do you manage tags?

@ifiokjr
Copy link

ifiokjr commented Jul 6, 2020

@zkochan I just did my first update using pnpm publish -r --tag next and it worked like a charm. Thanks for the tip.

I also like how you're managing releases for the pnpm project. I take it you're using changesets to generate the package specific changelogs and then you're manually adding your own top level changelog and github release. This strategy makes a lot of sense and I think I'll adopt it. With 80+ packages in remirror, creating unfiltered package releases has become too noisy.

@Andarist
Copy link
Member

Andarist commented Jul 7, 2020

@zkochan i think I've already asked this in the past, but... do you see any difference between our publishing script and pnpm publish -r? Would it be safe to just switch to pnpm entirely for this? Is there any required pnpm version for this command? Can the same be used for single package repos?

I would still be interested in investigating why this fails though:https://github.com/atlassian/changesets/blob/81595022e27e4b94a1bc87e56eabafb9a31e8315/packages/cli/src/commands/publish/npm-utils.ts#L126-L138

@zkochan
Copy link
Contributor

zkochan commented Jul 7, 2020

@Andarist we have discussed it here: #238

To summarize:

  • pnpm publishes packages in topological order
  • it works much faster than changesets

I think, when users use pnpm, it is safe to use pnpm publish -r in both single-package cases and multi-package repositories.

@Andarist
Copy link
Member

Andarist commented Jul 7, 2020

We've just released a new version of @changesets/cli with some additional logs for failed JSON.parse calls - if somebody could try running a publish with this new version this would be highly helpful in debugging this problem.

@talentlessguy
Copy link
Contributor Author

@Andarist hello, I tried it once again, here's the output:

error parsing json: 
πŸ¦‹  error SyntaxError: Unexpected end of JSON input
πŸ¦‹  error     at JSON.parse (<anonymous>)
πŸ¦‹  error     at jsonParse (/home/v1rtl/Coding/tinyhttp/node_modules/.pnpm/@changesets/cli@2.9.2/node_modules/@changesets/cli/dist/cli.cjs.dev.js:480:17)
πŸ¦‹  error     at internalPublish (/home/v1rtl/Coding/tinyhttp/node_modules/.pnpm/@changesets/cli@2.9.2/node_modules/@changesets/cli/dist/cli.cjs.dev.js:603:14)
πŸ¦‹  error     at processTicksAndRejections (internal/process/task_queues.js:93:5)

@devin-fee-ah
Copy link

devin-fee-ah commented Oct 21, 2020

Figured out the bug @Andarist @zkochan: there's a race condition between changesets publishing the manifests, and pnpm rewriting those manifests. That bug (from the perspective of changesets) happens here: https://github.com/pnpm/pnpm/blob/0b8fa3967067da8d4096c30b5e38fb462ed95220/packages/plugin-commands-publishing/src/publish.ts#L212-L223

I think, basically, changesets needs to throw the ball to pnpm on this one, and let it handle all the publishing.

@devin-fee-ah
Copy link

In case that appears to be a non-sequitor, the error actually comes from the manifest being published referencing another dependency in the monorepo, whose manifest is currently missing as it undergoes the pnpm transition.

@Andarist
Copy link
Member

@devin-fee-ah how this can result in a JSON.parse fail later? πŸ€” I understand that the manifest can not be updated properly but it seems like a potentially different problem.

I think, basically, changesets needs to throw the ball to pnpm on this one, and let it handle all the publishing.

This is probably the way to go for multiple reasons. Would you be willing to help us with this one? I probably won't have time to work on this one any time soon.

@devin-fee-ah
Copy link

devin-fee-ah commented Oct 21, 2020

Adding additional logging to /tmp/f/mono/.pnpm/@changesets/cli@2.11.1/node_modules/@changesets/cli/dist/cli.cjs.dev.js:

  // extra
  console.error(stdout.toString())
  console.error(stderr.toString())

  // original: ~L701 in function internalPublish
  let json = jsonParse(stdout.toString().replace(/[^{]*/, ""));

I get:

 ERROR  Cannot resolve workspace protocol of dependency "@mono/lib-foo" because this dependency is not installed. Try running "pnpm install".


error parsing json:
πŸ¦‹  error SyntaxError: Unexpected end of JSON input
πŸ¦‹  error     at JSON.parse (<anonymous>)
πŸ¦‹  error     at jsonParse (/tmp/f/mono/.pnpm/@changesets/cli@2.11.1/node_modules/@changesets/cli/dist/cli.cjs.dev.js:557:17)
πŸ¦‹  error     at internalPublish (/tmp/f/mono/.pnpm/@changesets/cli@2.11.1/node_modules/@changesets/cli/dist/cli.cjs.dev.js:705:14)
πŸ¦‹  error     at runMicrotasks (<anonymous>)
πŸ¦‹  error     at processTicksAndRejections (internal/process/task_queues.js:97:5)

That error is the one i'd mentioned above btw, @mono/lib-foo in that case no longer has a package.json after the process terminates, leading me to believe we're exiting while the manifest file is being deleted / created.

Now, for a different problem, I'm only getting pnpm to publish ~75% of my packages using pnpm publish (at the root). I can then manually go and publish the remaining ~12 packages.

@Andarist
Copy link
Member

Now, for a different problem, I'm only getting pnpm to publish ~75% of my packages using pnpm publish (at the root). I can then manually go and publish the remaining ~12 packages.

Is this caused by the mentioned problem or is it a different problem with Changesets or Pnpm itself?

@devin-fee-ah
Copy link

That last part is independent of changesets.

@Andarist
Copy link
Member

Gotcha, thank you for investigating this and providing more information. This is very helpful. I think at this point it's pretty obvious what we should do but there are no time resources in the team to handle this ourselves. I can provide guidance, reviews etc for anyone who would like to help out though.

@devin-fee-ah
Copy link

Alterrnatively, you could provide a third entrypoint –– "tag". So we'd have [version, publish and tag] allowing a user to override the publish step more easily.

The niceness of having tag as a separate entrypoint (breaking it out of publish) is that if publishing for an n'th package fails, and it's re-run... the tag for every package before the failed publish (on re-run) won't get tagged.

@Andarist
Copy link
Member

Could u prepare a separate issue for the tag describing the problem that it would fix? It would allow us for tracking this more easily as the proposal is separate (but related) to a problem here.

@devin-fee-ah
Copy link

Done. #478

@tpluscode
Copy link

I've been having a similar problem with one of my packages (not a monorepo). Here's an example of failed run: https://github.com/wikibus/Alcaeus/runs/1589751903?check_suite_focus=true

Is this the same problem? How do I resolve it?

@Andarist
Copy link
Member

Thanks for the report and link to the failed run - I will try to look into it but I have a lot on my plate right now so it might take a while. If you could investigate this further it could help us tremendously

@Andarist
Copy link
Member

@tpluscode it seems like literally npm profile has returned the same runtime error encoded in JSON a lot of times which ahs resulted in the incorrect JSON. This has happened here:
https://github.com/atlassian/changesets/blob/3c0f593a6632a4946fdaa16a06ef1add27cd6c69/packages/cli/src/commands/publish/npm-utils.ts#L61-L64

My bet is that this is actually caused by the fact that your project depends on gitbook which in turn depends (maybe indirectly) on some very old version of npm and this spawn calls to it instead of the global one that would actually return sensible results.

To fix this we'd have to figure out how to call the correct version of npm in this scenario.

@tpluscode
Copy link

Ah thank you for investigating. I have in fact started removing gitbook from the picture so I should good once its gone :)

@wesgro
Copy link

wesgro commented Jan 6, 2021

We were just bit by this on our last publish (curiously our first publish went fine, but once we published more packages it triggered whatever causes this)


[2021-01-05T21:25:14.339Z] > changeset publish

[2021-01-05T21:25:14.339Z] 

[2021-01-05T21:25:14.738Z] πŸ¦‹  info npm info @skyline/color-settings

[2021-01-05T21:25:14.738Z] πŸ¦‹  info npm info @skyline/icons

[2021-01-05T21:25:14.738Z] πŸ¦‹  info npm info @skyline/scss

[2021-01-05T21:25:14.738Z] πŸ¦‹  info npm info @skyline/tokens

[2021-01-05T21:25:14.738Z] πŸ¦‹  info npm info @skyline/vue

[2021-01-05T21:25:14.738Z] πŸ¦‹  info npm info @skyline/vuepress-theme-default

[2021-01-05T21:25:17.563Z] πŸ¦‹  info @skyline/color-settings is being published because our local version (2.0.0) has not been published on npm

[2021-01-05T21:25:17.563Z] πŸ¦‹  warn @skyline/icons is not being published because version 2.0.0 is already published on npm

[2021-01-05T21:25:17.563Z] πŸ¦‹  info @skyline/scss is being published because our local version (2.2.1) has not been published on npm

[2021-01-05T21:25:17.563Z] πŸ¦‹  info @skyline/tokens is being published because our local version (1.16.1) has not been published on npm

[2021-01-05T21:25:17.563Z] πŸ¦‹  info @skyline/vue is being published because our local version (4.3.0) has not been published on npm

[2021-01-05T21:25:17.563Z] πŸ¦‹  info @skyline/vuepress-theme-default is being published because our local version (0.4.17) has not been published on npm

[2021-01-05T21:25:17.563Z] πŸ¦‹  info Publishing "@skyline/color-settings" at "2.0.0"

[2021-01-05T21:25:17.563Z] πŸ¦‹  info Publishing "@skyline/scss" at "2.2.1"

[2021-01-05T21:25:17.563Z] πŸ¦‹  info Publishing "@skyline/tokens" at "1.16.1"

[2021-01-05T21:25:17.563Z] πŸ¦‹  info Publishing "@skyline/vue" at "4.3.0"

[2021-01-05T21:25:17.563Z] πŸ¦‹  info Publishing "@skyline/vuepress-theme-default" at "0.4.17"

[2021-01-05T21:25:21.227Z] error parsing json: 

[2021-01-05T21:25:21.228Z] πŸ¦‹  error SyntaxError: Unexpected end of JSON input

[2021-01-05T21:25:21.228Z] πŸ¦‹  error     at JSON.parse (<anonymous>)

[2021-01-05T21:25:21.228Z] πŸ¦‹  error     at jsonParse (.../node_modules/.pnpm/@changesets/cli@2.12.0/node_modules/@changesets/cli/dist/cli.cjs.dev.js:557:17)

[2021-01-05T21:25:21.228Z] πŸ¦‹  error     at internalPublish (/.../node_modules/.pnpm/@changesets/cli@2.12.0/node_modules/@changesets/cli/dist/cli.cjs.dev.js:711:14)

[2021-01-05T21:25:21.228Z] πŸ¦‹  error     at processTicksAndRejections (internal/process/task_queues.js:93:5)

[2021-01-05T21:25:21.228Z]  ERROR  Command failed with exit code 1.

For more context we publish to a private Jfrog Artifactory server instead of canonical NPM

@Andarist
Copy link
Member

Andarist commented Jan 6, 2021

It's really hard for us to repro this - given this occurs in very specific setups etc. Could you try to debug this? I would try rechecking what exact npm version is being used for publish and would also try out running publish with --dry-run. If you can't repro it locally it might be worth to patch-package changesets apply temporary changes for debugging purposes.

@dylanklohr
Copy link

Running into the same issue here when executing yarn changeset publish

  • Node:15.4.0
  • npm: 7.0.15
  • yarn: 1.22.10

However, executing npx changeset publish worked as expected

@nightire
Copy link

Had this same issue and was able to fix it by downgrading from npm7 to latest npm@6

Same here, I'd say npm@7 definitely has problems with changesets.

@Andarist
Copy link
Member

I think that the best way to move forward would be to handle publish using the APIs rather than CLI. This would allow us for more fine-grained control over the input arguments and the result. I'm afraid that I don't have time to work on that right now - but I would be happy to review a PR implementing this.

@danzGentrack
Copy link

 npx changeset publish
....
πŸ¦‹  error SyntaxError: Unexpected end of JSON input
πŸ¦‹  error     at JSON.parse (<anonymous>)
πŸ¦‹  error     at jsonParse (/home/user/my-project/node_modules/@changesets/cli/dist/cli.cjs.dev.js:584:17)
πŸ¦‹  error     at getTokenIsRequired (/home/user/my-project/node_modules/@changesets/cli/dist/cli.cjs.dev.js:632:14)
πŸ¦‹  error     at processTicksAndRejections (internal/process/task_queues.js:97:5)
πŸ¦‹  error     at async internalPublish (/home/user/my-project/node_modules/@changesets/cli/dist/cli.cjs.dev.js:715:8)

Got the same error. Turned out the call to npm profile get --json around cli.cjs.dev.js:632 failed with a 401 error, but the function getTokenIsRequired didn't expect it.

npm ERR! 401 Unauthorized - GET https://registry.npmjs.org/-/npm/v1/user
{
  "error": {
    "code": "E401",
    "summary": "401 Unauthorized - GET https://registry.npmjs.org/-/npm/v1/user",
    "detail": ""
  }
}```

For my use case, I want to publish a package to a private registry on AWS, e.g., `@my-scope/my-package` and I don't have a `registry.npmjs.org` login.

@reintroducing
Copy link

I also just ran into this using the changesets github action.

error parsing json: 
πŸ¦‹  error SyntaxError: Unexpected end of JSON input
πŸ¦‹  error     at JSON.parse (<anonymous>)
πŸ¦‹  error     at jsonParse (/home/runner/work/monorepo/monorepo/node_modules/@changesets/cli/dist/cli.cjs.dev.js:584:17)
πŸ¦‹  error     at internalPublish (/home/runner/work/monorepo/monorepo/node_modules/@changesets/cli/dist/cli.cjs.dev.js:738:14)
πŸ¦‹  error     at processTicksAndRejections (node:internal/process/task_queues:96:5)
Error: The process '/opt/hostedtoolcache/node/16.1.0/x64/bin/npm' failed with exit code 1
    at a._setResult (/home/runner/work/_actions/changesets/action/master/dist/index.js:86:6638)
    at a.CheckComplete (/home/runner/work/_actions/changesets/action/master/dist/index.js:86:6068)
    at ChildProcess.<anonymous> (/home/runner/work/_actions/changesets/action/master/dist/index.js:86:5102)
    at ChildProcess.emit (events.js:210:5)
    at maybeClose (internal/child_process.js:1021:16)
    at Process.ChildProcess._handle.onexit (internal/child_process.js:283:5)
Error: The process '/opt/hostedtoolcache/node/16.1.0/x64/bin/npm' failed with exit code 1

This is a very small test repo for me to evaluate changesets in a publish setting (proof of concept) so i'm happy to send my code over if it will help. I'm using the following:

node: 16.1.0
npm: 7.11.2

@bencergazda
Copy link

@zkochan @Andarist

I think, when users use pnpm, it is safe to use pnpm publish -r in both single-package cases and multi-package repositories.

pnpm publish -r fixed the Unexpected end of JSON input error also in my case (PNPM workspace). However, this does not create git tags, as how changests should do:

It is useful to have git tags of a publish, to allow people looking for the code at that time to find them. We generate tags in git during publish, but you will need to push them back up if you want to make them available. We recomend after publish you run:
git push --follow-tags

(https://github.com/atlassian/changesets/blob/main/docs/command-line-options.md#git-tags)

@bennypowers
Copy link

bennypowers commented Jul 1, 2021

with this patch

diff --git a/node_modules/@changesets/cli/dist/cli.cjs.dev.js b/node_modules/@changesets/cli/dist/cli.cjs.dev.js
index f771824..1577813 100644
--- a/node_modules/@changesets/cli/dist/cli.cjs.dev.js
+++ b/node_modules/@changesets/cli/dist/cli.cjs.dev.js
@@ -727,7 +727,8 @@ async function internalPublish(pkgName, opts, twoFactorState) {
     npm_config_registry: getCorrectRegistry()
   };
   let {
-    stdout
+    stdout,
+    stderr,
   } = await spawn__default['default'](publishTool.name, ["publish", opts.cwd, "--json", ...publishFlags], {
     env: Object.assign({}, process.env, envOverride)
   }); // New error handling. NPM's --json option is included alongside the `prepublish and
@@ -735,7 +736,7 @@ async function internalPublish(pkgName, opts, twoFactorState) {
   // some struggles
   // Note that both pre and post publish hooks are printed before the json out, so this works.
 
-  let json = jsonParse(stdout.toString().replace(/[^{]*/, ""));
+  let json = jsonParse(stdout.toString().replace(/[^{]*/, "") || stderr.toString().replace(/^npm ERR.*$/gm, '').replace(/[^{]*/, ""));
 
   if (json.error) {
     // The first case is no 2fa provided, the second is when the 2fa is wrong (timeout or wrong words)

I got this output:

πŸ¦‹  error an error occurred while publishing cem-plugin-async-function: ENEEDAUTH This command requires you to be logged in.
πŸ¦‹  error You need to authorize this machine using `npm adduser`
yarn run v1.22.10
$ yarn changeset publish
$ /Users/bennyp/Developer/cem-plugins/node_modules/.bin/changeset publish
πŸ¦‹  info npm info cem-plugin-async-function
πŸ¦‹  info npm info cem-plugin-copy
πŸ¦‹  info npm info cem-plugin-jsdoc-example
πŸ¦‹  info npm info cem-plugin-module-file-extensions
πŸ¦‹  info npm info cem-plugin-readonly
πŸ¦‹  info npm info cem-plugin-type-descriptions-markdown
πŸ¦‹  warn Received 404 for npm info "cem-plugin-async-function"
πŸ¦‹  warn Received 404 for npm info "cem-plugin-module-file-extensions"
πŸ¦‹  warn Received 404 for npm info "cem-plugin-copy"
πŸ¦‹  warn Received 404 for npm info "cem-plugin-type-descriptions-markdown"
πŸ¦‹  warn Received 404 for npm info "cem-plugin-readonly"
πŸ¦‹  warn Received 404 for npm info "cem-plugin-jsdoc-example"
πŸ¦‹  info cem-plugin-async-function is being published because our local version (0.0.1) has not been published on npm
πŸ¦‹  info cem-plugin-copy is being published because our local version (0.0.1) has not been published on npm
πŸ¦‹  info cem-plugin-jsdoc-example is being published because our local version (0.0.1) has not been published on npm
πŸ¦‹  info cem-plugin-module-file-extensions is being published because our local version (0.0.1) has not been published on npm
πŸ¦‹  info cem-plugin-readonly is being published because our local version (0.0.1) has not been published on npm
πŸ¦‹  info cem-plugin-type-descriptions-markdown is being published because our local version (0.0.1) has not been published on npm
πŸ¦‹  info Publishing "cem-plugin-async-function" at "0.0.1"
πŸ¦‹  info Publishing "cem-plugin-copy" at "0.0.1"
πŸ¦‹  info Publishing "cem-plugin-jsdoc-example" at "0.0.1"
πŸ¦‹  info Publishing "cem-plugin-module-file-extensions" at "0.0.1"
πŸ¦‹  info Publishing "cem-plugin-readonly" at "0.0.1"
πŸ¦‹  info Publishing "cem-plugin-type-descriptions-markdown" at "0.0.1"
πŸ¦‹  error an error occurred while publishing cem-plugin-async-function: ENEEDAUTH This command requires you to be logged in.
πŸ¦‹  error You need to authorize this machine using `npm adduser`
πŸ¦‹  error an error occurred while publishing cem-plugin-jsdoc-example: ENEEDAUTH This command requires you to be logged in.
πŸ¦‹  error You need to authorize this machine using `npm adduser`
πŸ¦‹  error an error occurred while publishing cem-plugin-copy: ENEEDAUTH This command requires you to be logged in.
πŸ¦‹  error You need to authorize this machine using `npm adduser`
πŸ¦‹  error an error occurred while publishing cem-plugin-module-file-extensions: ENEEDAUTH This command requires you to be logged in.
πŸ¦‹  error You need to authorize this machine using `npm adduser`
πŸ¦‹  error an error occurred while publishing cem-plugin-readonly: ENEEDAUTH This command requires you to be logged in.
πŸ¦‹  error You need to authorize this machine using `npm adduser`
πŸ¦‹  error an error occurred while publishing cem-plugin-type-descriptions-markdown: ENEEDAUTH This command requires you to be logged in.
πŸ¦‹  error You need to authorize this machine using `npm adduser`
πŸ¦‹  error packages failed to publish:
πŸ¦‹  cem-plugin-async-function@0.0.1
πŸ¦‹  cem-plugin-copy@0.0.1
πŸ¦‹  cem-plugin-jsdoc-example@0.0.1
πŸ¦‹  cem-plugin-module-file-extensions@0.0.1
πŸ¦‹  cem-plugin-readonly@0.0.1
πŸ¦‹  cem-plugin-type-descriptions-markdown@0.0.1
error Command failed with exit code 1.

which was a fair sight better than Unexpected end of JSON input.

This is using an NPM "automation token"

I was eventually able to publish by removing the "publishConfig" blocks from my package.jsons

@n1ru4l
Copy link

n1ru4l commented Jul 28, 2021

For anyone struggling out here:

I also tried setting up changesets for a single package repository and had the same issue as OP.

I also use the publishConfig option in my package.json:

{
  "publishConfig": {
    "access": "public",
    "directory": "dist"
  }
}

First I tried reverting from Node.js 16 to 14 (as 14 uses npm 6 instead of npm 7).

Doing so resulted in a more detailed error message:

πŸ¦‹  error an error occurred while publishing @n1ru4l/graphql-public-schema-filter: ENOPACKAGEJSON ENOENT: no such file or directory, open '/home/runner/work/graphql-public-schema-filter/graphql-public-schema-filter/dist/package.json'
πŸ¦‹  error npm can't find a package.json file in your current directory.
πŸ¦‹  error packages failed to publish:
πŸ¦‹  @n1ru4l/graphql-public-schema-filter@0.2.0
error Command failed with exit code 1.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.
Error: The process '/usr/local/bin/yarn' failed with exit code 1
Error: The process '/usr/local/bin/yarn' failed with exit code 1
    at a._setResult (/home/runner/work/_actions/changesets/action/master/dist/index.js:86:6638)
    at a.CheckComplete (/home/runner/work/_actions/changesets/action/master/dist/index.js:86:6068)
    at ChildProcess.<anonymous> (/home/runner/work/_actions/changesets/action/master/dist/index.js:86:5102)
    at ChildProcess.emit (events.js:210:5)
    at maybeClose (internal/child_process.js:1021:16)
    at Process.ChildProcess._handle.onexit (internal/child_process.js:283:5)

Which made me realize I forgot to run my build script πŸ™ƒ .

SO I reverted back to Node.js 16 and simply added the build step.

See these two commits:

n1ru4l/graphql-public-schema-filter@c3677b1
n1ru4l/graphql-public-schema-filter@a112aee

@Ptichi
Copy link

Ptichi commented Jul 31, 2021

I'm still getting this issue with npm7, any new insights?

error parsing json: 

πŸ¦‹  error SyntaxError: Unexpected end of JSON input

πŸ¦‹  error     at JSON.parse (<anonymous>)

πŸ¦‹  error     at jsonParse (/home/jenkins/agent/workspace/xSite_xsite-ui_master/node_modules/@changesets/cli/dist/cli.cjs.dev.js:584:17)

πŸ¦‹  error     at internalPublish (/home/jenkins/agent/workspace/xSite_xsite-ui_master/node_modules/@changesets/cli/dist/cli.cjs.dev.js:738:14)

πŸ¦‹  error     at processTicksAndRejections (internal/process/task_queues.js:95:5)

@bennypowers
Copy link

The documentation recommends setting NPM_TOKEN env var in CI. This doesn't work. Set NODE_AUTH_TOKEN instead.

@peschee
Copy link

peschee commented Aug 4, 2021

@bennypowers As we already discussed and found out, you actually have to set both NPM_TOKEN and NODE_AUTH_TOKEN

Β―_(ツ)_/Β―

@DavidWells
Copy link

I'm also seeing this. Unexpected end of JSON input

Seems like input is empty after running the pnpm command with these args

[
  'publish',
  '/x/repos/pnpm-workspaces/src/packages/package-d',
  '--json',
  '--access',
  'restricted',
  '--tag',
  'latest',
  '--no-git-checks'
]

Then the json parser breaks because the command is empty.

πŸ¦‹  error SyntaxError: Unexpected end of JSON input
πŸ¦‹  error     at JSON.parse (<anonymous>)
πŸ¦‹  error     at jsonParse (/x/repos/pnpm-workspaces/node_modules/.pnpm/@changesets+cli@2.16.0/node_modules/@changesets/cli/dist/cli.cjs.dev.js:585

The package.json for package-d is correct...

Has anyone found a fix for this issue?

@Decipher
Copy link

For me, I had to add the following to my package.json's:

  "publishConfig": {
    "access": "public"
  }

Answer from: https://stackoverflow.com/a/53478078

@rossng
Copy link

rossng commented Sep 25, 2021

I also ran into this issue when trying to publish my pnpm monorepo with changesets. There seem to be at least two issues here:

  • NPM commands are being run with the --json flag. Unfortunately a regression in NPM 7 (now the default version) means that both structured and unstructured output is all muxed onto stderr. This means the stdout is an empty string which fails to be parsed as JSON.
  • pnpm does not support the --json flag at all. However there are various places (example) where pnpm is called and the stdout is expected to contain JSON output.

On the first issue, I don't think there's much that can be done until NPM fixes the glaring regression.

I wouldn't mind trying to patch the second issue. I think the best thing would be to special-case pnpm - i.e. listen for the exit code of the pnpm process and, upon failure, pack the entire stdout/stderr output into the error. Would appreciate some guidance though.

@abdonrd
Copy link

abdonrd commented Oct 27, 2021

@Andarist
Copy link
Member

Andarist commented Nov 14, 2021

pnpm does not support the --json flag at all.

@rossng where did u get this info from? do u know of any pnpm + other stuff combination that fails to use --json with pnpm? i was just testing it and it seems to work. pnpm simply forwards almost all arguments to the npm (and it uses npm's CLI under the hood for publishing) so in a sense this should "just work". I've tested this manually with pnpm v6 and verified the code for v3, v4, v5, and v6 - they all do roughly the same thing when it comes to this args forwarding to npm publish.

There are news? Now I have the same error...

@abdonrd I'm trying to figure out the proper solution for most of the similar publishing issues to fix this once and for all. Stay tuned

@rossng
Copy link

rossng commented Nov 15, 2021

@Andarist I think you are right in the case of publishing. I had noticed that pnpm didn't support --json in the general case - that's what my comment was based on. However, I just had a quick look at the pnpm code and it does appear to forward anything in argv to npm when calling publish.

Glad to hear you are working on this - happy to help/test if needed.

@ifiokjr
Copy link

ifiokjr commented Nov 15, 2021

I had the same issue earlier today and it happened for two reasons.

Reason One

There was a package that was set to "private": true in the package.json file. This was unintentional. I attempted to fix this mistake in a recent release by updating the package.json. The problem is that the package already had multiple CHANGELOG.md entries and as a result, changesets attempts to update the package with a PUT rather than publish with a POST request. Since the package doesn't actually exist on the registry this causes an error and npm doesn't respond with json.

Fix: Make sure there is only one entry in your changelog file before publishing a package for the first time.

Reason Two

A package I was trying to publish seemed available, but it actually causes an error response from npm when trying to publish. The naming is too similar to another package that already exists. When an error happens the npm publish command doesn't return json and the json cannot be parsed.

Fix: Rename the package and retry.

Suggestions

I think the main problem is that changesets assumes that npm publish will always return valid json which is not the case. As a result the actual error response is hidden and all we see is an invalid json message.

https://github.com/atlassian/changesets/blob/fe8db7500f81caea9064f8bec02bcb77e0fd8fce/packages/cli/src/commands/publish/npm-utils.ts#L180

My suggestion is that this jsonParse call should be wrapped in a try catch and when failing it should log the original reponse from npm. This way it will be much easier to identify what the problem is.

Updated: Check for stderr before stdout so errors can be diagnosed more easily.

https://github.com/atlassian/changesets/blob/fe8db7500f81caea9064f8bec02bcb77e0fd8fce/packages/cli/src/commands/publish/npm-utils.ts#L169-L175

@ifiokjr
Copy link

ifiokjr commented Nov 15, 2021

@Andarist
Copy link
Member

Yep, already pushed out a change like this a couple of hours ago πŸ˜‰ :

89a70f9

Need to self-review and retest this before publishing a PR.

Thank you also for other comments - i will take a deeper look into everything you have mentioned

@Andarist
Copy link
Member

I've created a pull request that attempts to fix the issues mentioned here. I will setup snapshot releases for this PR soon-ish but in the meantime I would love to ask if there are any people willing to test this stuff out in their projects.

@kulasekara02
Copy link

Does anyone have solutions for this lol

@stefan-karlsson
Copy link

I managed to get the github action to work using this setup.

name: Release

on:
  push:
    branches:
      - main

concurrency: ${{ github.workflow }}-${{ github.ref }}

env:
  GITHUB_TOKEN: ${{ secrets.GH_RELEASE_TOKEN }}
  NPM_TOKEN: ${{ secrets.GH_RELEASE_TOKEN }}
  NODE_AUTH_TOKEN: ${{ secrets.GH_RELEASE_TOKEN }}

jobs:
  release:
    name: Release
    runs-on: ubuntu-latest
    steps:
      - name: Checkout Repo
        uses: actions/checkout@v3

      - name: Setup Node.js 18.x
        uses: actions/setup-node@v3
        with:
          node-version: 18.x
          cache: 'npm'
          token: ${{ secrets.GH_RELEASE_TOKEN }}
          registry-url: 'https://npm.pkg.github.com'

      - name: Install Dependencies
        run: npm ci

      - name: Create Release Pull Request or Publish to npm
        id: changesets
        uses: changesets/action@v1
        with:
          publish: npm run release

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet