Xterm.js: ES6 module no export Terminal

[elgs]

When I follow the doc to import Terminal as an ES6 module.

The recommended way to load xterm.js is via the ES6 module syntax:

import { Terminal } from 'xterm';

I got the following error. I opened the xterm.js and found it's an minified js file and it indeed didn't export Terminal.

The requested module '../../../node_modules/xterm/lib/xterm.js' does not provide an export named 'Terminal'

I'm not using any building tools. I just used plain ES6 import syntax.

[Tyriar]

I don't know the details here on what TS does but TS works for me. I guess this is requesting a native ESM target which has come up before https://github.com/xtermjs/xterm.js/issues/2486

[elgs]

What I am wondering is I've seen a few other libraries claiming they are supporting ES6, but they are in the same situation like this, like this one https://github.com/highlightjs/highlight.js/issues/2473. They use Rollup to build the library. I'm not familiar with Rollup.

My understanding of ES6 module is the library has some code syntax like:

export something = someFunction;

And the client is like:

import { something } from 'node_modules/someLib/someLib.js';

something();

I wonder if I misunderstood what ES6 is.

[elgs]

This is a big deal, because with the REAL ES6 support, the client can get rid of the dependency of build tools, though the build tools are awesome, but at least it's not necessary.

[Tyriar]

Yeah it would be nice to be on the latest and greatest but then you lose support for other better supported ways of importing. Eventually we'll move there but shipping a library that supports many different import types is tricky.

[elgs]

I understand that. That's why if you look at the lodash package, they released a separate package called lodash-es. That is the REAL ES6 support. But unfortunately the export syntax is illegal in the nodejs like module system.

You mentioned:

but then you lose support for other better supported ways of importing

Actually, no, you don't lose anything in browser. All modern build tools support the REAL ES6 syntax. What you lose is the support to build for nodejs users. But for packages like xterm, and highlightjs, why does it matter at all. Who use them in Nodejs.

[elgs]

lodash releases two separate packages for a wise reason, one for Nodejs and the other for browsers. Because the natural of lodash is that it is used in both Nodejs and browsers. In the old days, Javascript didn't have any module system in the browser, everything is bound to window, so that's why many build tools did many tricky things to translate the Nodejs module system to the browser window. That's understandable before REAL ES6 is usable in the browsers. Now ES6 is natively supported by browsers, packages like xterm and highlightjs should have no reason go around to the Nodejs module system.

[justinfagnani]

Is there any chance of moving to native modules in a major release? Every current major browser, and the past 3 major (soon to be 4 next moth) of Node, supports modules natively.

@Tyriar

then you lose support for other better supported ways of importing. Eventually we'll move there but shipping a library that supports many different import types is tricky.

I don't think there are better ways of importing than native modules. Every other way requires tools or userland loaders, and can be targeted with native modules and a tool anyway.

At this point I really don't think it'd even be worth it to publish two packages. Applications that support older browsers can really easily consume JS module dependencies and compile them to a different format. It's the default behavior for Rollup and Webpack.

One problem with not publishing standard JS modules is that you library is shut off from those that are using native modules. I'm trying to use a terminal widget for a project, but all my libraries are modules only, and there's no good way to import UMD from native modules.