You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
p-limit 4 dropped commonjs style import support. Though one very practical issue we encounter was that even if "our" project uses ESM, since there are still many libraries we use executes require("p-limit"), so we had no choice but forced to use p-limit 3.
I understand that ESM is the best practice and the future, but practically, the third party require("p-limit") issue will prevent us (and many others) from using p-limit 4 for many years, if not ever.
The text was updated successfully, but these errors were encountered:
since there are still many libraries we use executes require("p-limit"), so we had no choice but forced to use p-limit 3.
They should be able to continue using it. The whole dependency tree does not need to be ESM. npm will only hoist compatible (based on semver ranges) packages to the top-level. Node.js can have multiple versions of the same package running at the same time.
Oh ok, let me double check. IIRC, last week, we tried to upgrade p-limit to 4 but then encountered errors pointing to require("p-limit") in third party source codes that hadn't happened before, but haven't investigated in detail.
p-limit 4 dropped commonjs style import support. Though one very practical issue we encounter was that even if "our" project uses ESM, since there are still many libraries we use executes
require("p-limit")
, so we had no choice but forced to use p-limit 3.I understand that ESM is the best practice and the future, but practically, the third party
require("p-limit")
issue will prevent us (and many others) from using p-limit 4 for many years, if not ever.The text was updated successfully, but these errors were encountered: