Add compatibility keyword based on modularity type #3326
andrew-aladev
started this conversation in
Ideas
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Please review the following gist and issue.
@sindresorhus is the author of 1407 small packages. He tries today to use popularity on
npm
/yarn
for forcing ESM, please review a list of his packages. 90% of these packages provides a new major version with ESM only dist.For example
string-width
has been downloaded 302.6 million times and now it is ESM only. It may be funny with amount of downloads about 1K, but now it is not funny and it won't be funny anymore.He just dropped support of CommonJS modularity type. But any user can still install a new version of package with incompatible modularity type and
npm
/yarn
won't care. Packages provide just small utilities and developer may use them in small scripts outside of main project tests. Developer will think that "this package is too small, it can't provide any harm for me", he will upgrade it and nothing will happen.ERR_REQUIRE_ESM
will appear in runtime only (for example in production).I am sure that
npm
/yarn
should care about modularity type and implement it ASAP, because bomb has already been planted by @sindresorhus.For example gentoo
portage
has a specialkeywords
for different architectures: package will be masked for unknown/untested architecture and system won't install such packages without your explicit permission. Rubybundler
hasplatforms
keyword for same purpose. Please add similar keyword for nodejs modularity type.Please also review an idea to bind modularity type and popularity together. It means that
string-width
has been downloaded 302.6 million times usingCommonJS
modularity type. New version ofstring-width
withESM
only modularity type should have 0 popularity.Thank you.
Beta Was this translation helpful? Give feedback.
All reactions