What import is more correct?

[adinvadim]

import * as R from 'fp-ts/lib/Record';
import * as A from 'fp-ts/lib/Array';
import { pipe } from 'fp-ts/lib/function'

I always import like this. But in issues and few examples see import like (without lib in path)

import * as R from 'fp-ts/Record';
import * as A from 'fp-ts/Array';
import { pipe } from 'fp-ts/function'

What is more correct? or doesnt matter?

[pashutk]

Hi!

Either way is correct. Second approach will work only if you build system is aware what module type should be used (commonjs or es6).

If you want more details you can read about transition between first and second approach in this pull request: #1241.

[pashutk]

It was introduced in 2.8.0 by the way https://github.com/gcanti/fp-ts/releases/tag/2.8.0

[adinvadim]

Thank you for link!

[albohlabs]

In thenode_modules/fp-ts/Array folder there is package.json with the following content:

{
  "main": "../lib/Array.js",
  "module": "../es6/Array.js",
  "typings": "../lib/Array.d.ts",
  "sideEffects": false
}

The important part is the module prop which the Rollup docs describes pretty well:

To make sure your ES modules are immediately usable by tools that work with CommonJS such as Node.js and webpack, you can use Rollup to compile to UMD or CommonJS format, and then point to that compiled version with the main property in your package.json file. If your package.json file also has a module field, ES-module-aware tools like Rollup and webpack 2+ will import the ES module version directly. https://rollupjs.org/guide/en/#publishing-es-modules

This means that the import from fp-ts/Array is handled as esm (es-module, ECMAScript module) and comes imo with two major benefits:

• tree-shakeable https://exploringjs.com/es6/ch_modules.html#static-module-structure
• works in the browser https://caniuse.com/es6-module

The lib folder contains modules that are in CommonJS format which was the nodejs standard before esm becomes the official standard format to package JavaScript code.
So the reason this folder exist is to provide backward compatibility.

[qlonik]

I've been investigating it too a bit. It seems that this approach with lots of package.json files in folders doesn't work with node16/nodenext. It really needs just one top-level package.json with exports map.

[steida]

@gcanti Do you plan to release fp-ts 3 with simple package.json? I think a lot of package.json files also break types in Deno esm-dev/esm.sh#300

[gcanti]

@steida current v3 (3.0.0-alpha.22) has just one top-level package.json with exports map and seems to work fine, so I'd say yes

[rawnly]

@steida current v3 (3.0.0-alpha.22) has just one top-level package.json with exports map and seems to work fine, so I'd say yes

@gcanti Any eta on this? 👀

[gcanti]

@rawnly a top-level package.json with exports map will be in 2.13 https://github.com/gcanti/fp-ts/milestone/60?closed=1