Open wereHamster opened 4 years ago
tsc targeting table:
main | module | |
---|---|---|
es5 | es5 | current fp-ts v2.x |
es5 | es2019 | picked up by bundle tooling only (rollup, webpack etc.) |
es2019 | es2019 | additional runtime boost without bundling, 100% compatible with Node.js v12 |
Given Node.js
v10 already end of life at 30-Apr-2021, also planned fp-ts
v3 is an major bump, I think it would be great to have both targeting to es2019.
edit: adding Node.js ECMAScript compatibility tables:
Also, the import
statements don't use module specifiers ending in .js
, so if I try to just load those modules up they don't actually work.
Also, the
import
statements don't use module specifiers ending in.js
, so if I try to just load those modules up they don't actually work.
Just make a PR that resolves imports to proper HTTP/S locations. But don't call it *.js
, go for *.mjs
. The difference is "strict mode", e.g. two variables with the same name in *.js
mix themselves up.
🚀 Feature request
Current Behavior
The "module" file uses ES6 import/export syntax, however the code itself is downcompiled to ES5. This means the file does not use class syntax, arrow functions, rest spread etc. The reason is to make it compatible with IE11 (see #1110), however that is a bad idea since it basically forces larger bundles to everybody.
This issue exists even moreso in the io-ts repo, which uses class syntax quite heavily.
Desired Behavior
The "module" file should target modern syntax (ES6+, ideally latest ES, currently ES2020). If people need these modules to work in older browsers, they should set up their bundlers appropriately.
Projects using create-react-app already transpile all files, even those in node_modules, so this change shouldn't be a problem for those projects. Next.js has a plugin for that.
Suggested Solution
At the very least undo #1110, or even better set "target" to "es2020". Same in the io-ts repo.