Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Automatic ESM/CJS redirection #4

Open
jer-sen opened this issue Feb 7, 2024 · 0 comments
Open

Automatic ESM/CJS redirection #4

jer-sen opened this issue Feb 7, 2024 · 0 comments

Comments

@jer-sen
Copy link

jer-sen commented Feb 7, 2024

Not sure that it is the good place for this issue, but it's a global issue for all react-component modules and it's linked to the build.

If we agree that an ESM should always use ESM version of RC modules and that a CJS module should always use CJS version, then package.json of all RC modules should be improved with this patch:

-  "main": "./lib/index",
-  "module": "./es/index",
+  "exports": {
+    ".": {
+      "types": {
+        "import": "./es/index.d.ts",
+        "default": "./lib/index.d.ts"
+      },
+      "import": "./es/index.js",
+      "default": "./lib/index.js"
+    },
+    "./*": {
+      "types": {
+        "import": "./es/*",
+        "require": "./lib/*"
+      },
+      "import": "./es/*",
+      "require": "./lib/*"
+    }
+  },

It will fix an issue faced in some modules build to ESM and CJS (such as antd and all RC modules) since path of imports must be fixed (replacing /lib/ with /es/) during the build process (which is complex and not always done, an example here node_modules/antd/es/form/index.d.ts with import type { Rule, RuleObject, RuleRender } from 'rc-field-form/lib/interface';).
It would make babelPluginImportLib2Es of father-plugin useless since Node/TS/bundlers would automatically add the right es or lib prefix when importing/requiring a file of an other RC module from source or es or lib folder. Note that, for this to work, files in es folder should be considered as ESM (files should use .mjs extension or a package.json with "type": "module" should be added to es folder) which is not the case today (bug!). There is a pending PR to fix this bug in father: umijs/father#742

It should be possible to make this change in a backward-compatible manner with this alternative patch which will block access to es from a CJS module and lib from an ESM module:

-  "main": "./lib/index",
-  "module": "./es/index",
+  "exports": {
+    ".": {
+      "types": {
+        "import": "./es/index.d.ts",
+        "default": "./lib/index.d.ts"
+      },
+      "import": "./es/index.js",
+      "default": "./lib/index.js"
+    },
+    "./es/*": {
+      "types": {
+        "import": "./es/*"
+      },
+      "import": "./es/*"
+    },
+    "./lib/*": {
+      "types": {
+        "require": "./lib/*"
+      },
+      "require": "./lib/*"
+    },
+    "./*": {
+      "types": {
+        "import": "./es/*",
+        "require": "./lib/*"
+      },
+      "import": "./es/*",
+      "require": "./lib/*"
+    },
+  },

Or if we want to be 100% backward-compatible (what I don't recommend because it allows a misuse of RC module) we can keep access to wrong paths with:

-  "main": "./lib/index",
-  "module": "./es/index",
+  "exports": {
+    ".": {
+      "types": {
+        "import": "./es/index.d.ts",
+        "default": "./lib/index.d.ts"
+      },
+      "import": "./es/index.js",
+      "default": "./lib/index.js"
+    },
+    "./es/*": {
+      "types": {
+        "import": "./es/*",
+        "require": "./es/*"
+      },
+      "import": "./es/*",
+      "require": "./es/*"
+    },
+    "./lib/*": {
+      "types": {
+        "import": "./lib/*",
+        "require": "./lib/*"
+      },
+      "import": "./lib/*",
+      "require": "./lib/*"
+    },
+    "./*": {
+      "types": {
+        "import": "./es/*",
+        "require": "./lib/*"
+      },
+      "import": "./es/*",
+      "require": "./lib/*"
+    },
+  },
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant