The idea is to use separate entrypoints for Node.js and universal (runs both on browser and Node.js) code. This is accomplished via browser field and exports field.
I intentionally name it as "universal" instead of "browser". If we end up adding some browser-only code to commons, it would make sense to separate this into multiple packages, because this can't be easily done without using exports only, which is not backwards compatible. Also, having a single package for these 3 cases is pretty complex.
I double checked the usage on a freshly created FE app and one of our private Node.js services.
Closes https://github.com/api3dao/commons/issues/45 Related to https://github.com/api3dao/commons/pull/18
Rationale
The idea is to use separate entrypoints for Node.js and universal (runs both on browser and Node.js) code. This is accomplished via browser field and exports field.
I intentionally name it as "universal" instead of "browser". If we end up adding some browser-only code to commons, it would make sense to separate this into multiple packages, because this can't be easily done without using
exportsonly, which is not backwards compatible. Also, having a single package for these 3 cases is pretty complex.I double checked the usage on a freshly created FE app and one of our private Node.js services.