Unable to publish packages with different name to publish URL as of 07/10/2020

We use Github Packages to host Unity Package Manager packages (npm under the hood).

Today we’ve started getting the following error when publishing:

npm ERR! code E400
npm ERR! 400 Bad Request - PUT https://npm.pkg.github.com/@electricplaybox/com.electricplaybox.test - name in package.json "com.electricplaybox.test" does not match publish URL "@electricplaybox/com.electricplaybox.test"

npm ERR! A complete log of this run can be found in:
npm ERR!     C:\Users\Matt\AppData\Roaming\npm-cache\_logs\2020-10-08T15_47_42_234Z-debug.log

The URL’s don’t match intentionally, because UPM does not support packages names with the @ character in them.

Has anyone else run into this issue today?

Many thanks,


I’m suffering from the same problem, did you manage to solve it?

1 Like

Not yet, I have raised a support ticket with GitHub support, will update as soon as I know more.

1 Like

thank you very much, I don’t want to rename the package!

Hi folks :wave:

I’m afraid this change was by design.

Too many users were getting mixed up between the following configurations:


As you’ve discovered, the second configuration will promote an unscoped package into the @OWNER scope. Restoring packages using this configuration does the opposite. This was an unintended feature and shouldn’t be possible! I don’t think it works this way when publishing to npmjs.org.

I’m wondering if there might be an alternative workaround people could use. We only check the package name when publishing, not when downloading a package.

This means you can publish a scoped package, but install it as if it didn’t have a scope. For example, here I’m using npm install upm-test to install the @jcansdale-test/install upm-test package:

I wonder if the Unity Package Manager behaves in a similar way and whether it sanity-checks the names of downloaded packages?

There is no guarantee this will work, but it’s maybe worth a try. If you do attempt this, please let me know!

That work around, it’s no good.

Unity does not support this: @scope/com.something.packagename


Can confirm that this work around does not work, and we get the same error on the UPM end saying that the package name and repo URL do not match while trying to download the package.

Is there any way to turn this feature off for users who know what they are doing / know what they are doing is confusing?


Hello! I faced this same issue.

I had to change my package.json

I changed the name to be like

name: "@electricplaybox/com.electricplaybox.test"

and changed the publishConfig to

  "publishConfig": {
    "registry": "https://npm.pkg.github.com"

I don’t know about you, but I had the owner at the end of my registry, like "registry": "https://npm.pkg.github.com/@electricplaybox"

and after all, the .npmrc looks like this:


Hope it helps!

That indeed allows to upload the package, but the problem is that with the Unity game engine we cannot install it, since unfortunately Unity doesn’t support names with the scope (@xxxx/).

I guess the issue is really with Unity for not supporting that, but I don’t see they changing it any time soon or for current engine versions :frowning_face:

Just a quick not to say that we are also experiencing this problem and are no longer able to publish the packages that we use in Unity.

Best regards,
Tactile Games

Hi Friends!

We have just deployed a fix that will allow for the publishing of unscoped packages, but only if the package name contains a . in it. Ideally this should re-enable the workflows you’ve been blocked on for the past few days.

Happy Unity-ing!


I can confirm it’s working fine, thanks a lot!

1 Like

I can also confirm that this latest change re-enables github package support for Unity.

Confirming that we are able to publish packages again!

Many thanks @toddself!

@toddself Somebody from Unity says that the change is temporary, is that so?



yes but we have not worked out a time frame yet. the tl;dr is that this was something that wasn’t being properly checked on our end, and should have never worked :slight_smile:.

hopefully we can come to an equitable resolution for this matter with the team at unity!

i cannot give any official (or unofficial) information on what the timeline for removing this is, but we did just fix it so it’ll be a bit down the road!