Thanks for putting this together! 👏

I wonder what meta will look like for a package where a specific version was unpublished, rather than every version. The latter is npm's default, but you can specify a version in npm unpublish.

As for how to find a sample, perhaps left-pad still has older versions that are unpublished and were never restored.

I've just tested, and here is the result:
(I've unpublished the 0.0.1)

{
  // ...
  'dist-tags': { latest: '0.0.2' },
  versions:
   { '0.0.2':
      {
      //...
      }
   },
  time:
   { created: '2018-08-28T17:03:13.524Z',
     '0.0.1': '2018-08-28T17:03:13.692Z',
     modified: '2018-08-28T17:07:04.066Z',
     '0.0.2': '2018-08-28T17:06:04.272Z' },

Awesome, that's about what I would have expected.

The reason that matters is that squatter takes a second (currently undocumented) version argument. I'm not sure if there is a strong use case for it, but I implemented it so that i could use it in the tests if it turned out that the integration tests were too flakey, since they use the latest of real packages and someone could publish a new version that breaks those tests at any time. So far that has never been a problem, but I'm keeping an eye on it.

Anyway, in order to handle the version argument correctly, I guess unpublished() would have to first resolve the version using dist-tags (but handle it not existing) and then check if that version exists in Object.keys(meta.versions). Based on the output you posted in the issue, it seems like when all versions are unpublished, they move meta.versions to meta.time.unpublushed.versions. So I suppose it would have to handle that, too.

Or to simplify everything, we could get rid of the version argument.

Hmm, I 'm not sure to get it 😕

Being unpublished cannot depend on a version: a package is either completely unpublished (so not a squatter), either has one or more published versions, in that case the additional tests need to be run.

By the way, I really don't understand how npm works:
I've unpublished all the versions of my imaginary package (I don't remember the order tho), and here is what the meta looks like:

{
  // ...
  'dist-tags': { latest: '0.0.2' },
  versions: { 
    '0.0.2': {
    // ...
    }
  },
  time:
   { created: '2018-08-28T17:03:13.524Z',
     '0.0.1': '2018-08-28T17:03:13.692Z',
     modified: '2018-08-28T19:34:12.799Z',
     '0.0.2': '2018-08-28T17:06:04.272Z',
     '0.0.3': '2018-08-28T17:19:48.544Z',
     '0.0.4': '2018-08-28T17:22:03.420Z',
     '0.1.0': '2018-08-28T19:21:15.659Z' },
  }

I really don't get it. The npmjs.com page shows a 404, but the unpkg.com site still has the 0.0.2 version (and only this one).

Note: It may change in a few hours, because the npm command line says I should wait 24 hours after a package is completely unpublished to publish again.

As the owner, you can choose to unpublish all versions or only some versions. The default behavior when you run npm unpublish is to unpublish all versions, but people can choose to unpublish specific versions if they feel like it (e.g. 0.0.2 had a major security flaw, but 0.0.3 has the fix, and you want to unpublish only 0.0.2 to ensure no one is affected by the security flaw).

So unpublishing depends upon versioning in the same way that publishing does. The only part I'm not super familiar with is how they represent this in the registry data. I'll help investigate that and see if there is a way for us to tell that a specific version was unpublished or whether the entire namespace was unpublished. Give me a few days and I'll look into it!

Any follow-up on this? I recently was using npm-name-cli which uses squatter as a dependency -- I was looking to publish zark but as far as I can tell from the registry it is unpublished / squatted upon by the user ~zark:

npm-name zark
⠇ Checking name on npmjs.com…

Sat and hung for a while, until I hit Ctrl-C and then I saw:

^CTypeError: Cannot read property 'latest' of undefined
    at versionPkg (/[...]/.config/yarn/global/node_modules/squatter/lib/get-package.js:9:36)
    at squatter ([...[/.config/yarn/global/node_modules/squatter/index.js:42:17)
    at process._tickCallback (internal/process/next_tick.js:68:

I'd love to be able to use npm-name / squatter to track this status.

I will be fixing this, for sure. Most likely merging this PR as-is. I just need to find the time to verify my assumptions about the registry data are correct. Tentatively thinking I should be able to do that middle of this week. Soon as this is done, I will make a patch release. Thanks for your patience. :)

any updates on this? @sholladay

Hi! I finally got around to this. Ready to merge with that one tweak. Thanks for your patience. :)

@bokub Ping

Hi Sindre
I can't edit my PR because I've deleted the fork a long time ago 🙃
Maybe @sholladay can make an edit before or after merging?

If not, I'll make a new PR tomorrow when I'm around a computer

For some reason, GitHub will allow me to merge, but not edit. I presume this is because the fork was deleted.

Don't worry about recreating the fork. What I'll do is squash merge and then amend the commit on master.

Thanks for your work on this!

I've duplicated this PR in #5 😊

@sholladay Ping 🙋

I merged PR #5. Thanks for your work. I am aiming to do a release next weekend, possibly sooner.

@sholladay Reminder about releasing.

This fix has been released. Thanks for your patience, y'all. I've been taking care of my father who is very sick. I'm behind on many things, but OSS keeps me going. :)