es2015-i18n-tag@1.6.2 package broken

[nor3]

latest package does not contain dist folder so load module failed.

# npm install es2015-i18n-tag
+ es2015-i18n-tag@1.6.2
added 1 package from 1 contributor in 0.944s
# cd node_modules/es2015-i18n-tag/
# ls -lR
.:
total 272
-rw-r--r--. 1 root root   5268 Jan 19 22:15 benchmark.js
-rw-r--r--. 1 root root      0 Jan 19 22:15 CHANGELOG.md
-rw-r--r--. 1 root root   2528 Jan 19 22:15 CONTRIBUTING.md
-rw-r--r--. 1 root root   1081 Jan 19 22:15 LICENSE
-rw-r--r--. 1 root root   4469 Jan 20 14:00 package.json
-rw-r--r--. 1 root root  20006 Jan 19 22:15 README.md
-rw-r--r--. 1 root root 233307 Jan 19 22:15 yarn.lock

[skolmer]

Thanks for reporting. Not sure what went wrong. For now you can use v1.6.1. I will look into it when I find some time.

[skolmer]

I have set the package version to deprecated.

[AndyOGo]

@skolmer Within 24 hours you could have removed this version from NPM, guess is too late now.

And I guess deprecation is misleading, NPM says this package has been deprecated, not that version...

[skolmer]

@AndyOGo I have deprecated the specific version of this package via npm cli. You can see it in the version history if you set deprecated versions to visible.
Do you mean using unpublish command? I'm not sure what would have been the best procedure in a case like this. My intention was to avoid that other users are auto migrating to this broken package because of a patch version rule. I went by the recommendations of npm documentation:

It is generally considered bad behavior to remove versions of a library that others are depending on!

[skolmer]

Wee need better scripts/testing to avoid f***ups like this #72

[AndyOGo]

@skolmer
Yeah that's right, in general packages shouldn't be removed.
left-pad has shown what can happen...
https://qz.com/646467/how-one-programmer-broke-the-internet-by-deleting-a-tiny-piece-of-code/

But I would argue, since this version isn't working at all and unpublish allows you to target specific versions it would have been the better choice, cause caret instalations like ^1.6.1 will always pull 1.6.2 until it is replaced.

Btw. I have to correct myself, you can unpublish within 72 hours:

With the default registry (registry.npmjs.org), unpublish is only allowed with versions published in the last 72 hours. If you are trying to unpublish a version published longer ago than that, contact support@npmjs.com.
https://docs.npmjs.com/cli/unpublish

[skolmer]

Ok, I can follow that argumentation. I have now unpublished this package version. I had the impression that semver caret handling will exclude deprecated versions but couldn't find any documentation on that. So now everyone should be safe from getting a broken package.

[AndyOGo]

Great, just keep in mind, that you can't reuse that version number 1.6.2.

Even if a package version is unpublished, that specific name and version combination can never be reused. In order to publish the package again, a new version number must be used.
https://docs.npmjs.com/cli/unpublish#description