gcanti / fp-ts

Functional programming in TypeScript
https://gcanti.github.io/fp-ts/
MIT License
10.85k stars 503 forks source link

Provide files compiled for modern (ES6 or later) targets #1253

Open wereHamster opened 4 years ago

wereHamster commented 4 years ago

🚀 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.

imcotton commented 3 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:

SamB commented 1 year ago

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.

kungfooman commented 1 year ago

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.