Can import @turf packages as "npm imports" but not as "node imports"

[jamesscottbrown]

This works:

import { center } from "npm:@turf/center";
import { points } from "npm:@turf/turf";

const features = points([
  [-97.522259, 35.4691],
  [-97.502754, 35.463455],
  [-97.508269, 35.463245],
]);
const p = center(features);

But I can't use a "node import" to import from node_modules/ after running npm install.
This code:

import { center } from "@turf/center";

Displays this error message in the page:

TypeError: The specifier “util” was a bare specifier, but was not remapped to anything. Relative module specifiers must start with “./”, “../” or “/”.

Similarly, import * as turf from "npm:@turf/turf"; works, but import * as turf from "@turf/turf"; gives an error.

See https://turfjs.org/docs/api/center and https://www.npmjs.com/@turf/center

[mbostock]

The problem is likely that turf (in @turf/helpers) depends on deep-equal which is not distributed as an ES module.

https://cdn.jsdelivr.net/npm/@turf/[email protected]/dist/esm/index.js

https://cdn.jsdelivr.net/npm/[email protected]/index.js

Framework doesn’t automatically isn’t always able to convert CommonJS to standard modules. You’ll have better luck using modules that are naturally distributed as ES modules (including all transitive dependencies).

[jamesscottbrown]

I think you have correctly identified the problem.

Framework doesn’t automatically convert CommonJS to standard modules

That is useful to know. The "Note" in the Node imports section of the docs states that:

Not all Node packages are usable in the browser; Node imports are only supported for modules that do not rely on Node-specific APIs and that can be converted to ES modules via esbuild.

(emphasis mine)

I had interpreted this to mean that if a package could be converted to ES modules by esbuild, then it would be converted; evidently I misunderstood.

Perhaps the note should be edited to instead say something like "...and for which the module and all of its transitive dependencies are ES modules. You may be able to convert a package into an ES module using esbuild.".

This particular package can be converted by esbuild - I've just checked, and I am able to convert it by:

• installing esbuild with npm install --save-exact --save-dev esbuild
• bundling with ./node_modules/.bin/esbuild ./node_modules/@turf/center/dist/esm/index.js --bundle --format=esm --outfile=src/center.js
• doing a local import with import {center} from "./center.js"

[mbostock]

Sorry, I misspoke slightly: Framework does indeed make an effort to convert CommonJS to ES modules using esbuild. However, it only works when esbuild is able to convert that module, and all of its transitive dependencies, to ES modules successfully. If the module (or a transitive dependency) is CommonJS, this requires the module to be compatible with cjs-module-lexer.

When Framework converts a package to an ES module, it doesn’t bundle the package with its transitive dependencies; instead, it bundles each package independently. This is done to avoid duplicate copies of dependencies. For example, if you have packages parent1 and parent2 that each depend on child, then if you were to bundle parent1 and parent2 separately, by default you’d get two copies of child (one baked into each parent). Framework uses esbuild’s external option to prevent packages from being combined when bundling. (But modules within a package are still bundled.) Also, duplicate copies of dependencies can change runtime semantics.

So, even though esbuild can bundle @turf/center and all its dependencies into a single ES module, it (seemingly) isn’t able to separately bundle @turf/center and all its dependencies as separate ES modules. That’s because when combining into a single ES module, esbuild can use tree shaking to avoid bundling some of the code. And deep-equal has a massive tree of dependencies (which tends to be acceptable in the Node ecosystem, but is rarely desirable when loading libraries over the network in a browser).

Anyway, there’s probably a workaround we can do to make Framework/esbuild handle this tree of dependencies better. But the ecosystem is a bit of a mess, so it’s also good if library developers standardize on ES modules, and try to avoid giant dependency trees if possible.

[mbostock]

I have confirmed that this issue was fixed in Turf.js 7.0.0 and that currently imports of both @turf/turf and npm:@turf/turf work out of the box in recent versions of Framework (1.6.0+).

import * as turf from "npm:@turf/turf";

import * as turf from "@turf/turf";

We still recommend using npm imports over Node imports as npm imports do not require you to explicitly manage dependencies yourself.