Use ES Modules in es-abstract

[12wrigja]

Are there any plans to use ES Modules in es-abstract?

I'm evaluating the feasibility of using es-abstract with the Closure Compiler and this would be significantly easier if es-abstract was using ES Modules (as the compiler understands those better than commonjs modules).

[ljharb]

Adding exports (a necessary precondition for using ESM) is a breaking change.

I'm not sure how it would be different though; the non-deprecated way to use abstract operations is with a deep link, of which each would only have a default export, so I'm not sure what difference ESM vs CJS would make.

[ljharb]

In general, I'd advise against using a tool that can't understand statically required CJS modules, as they are identically understandable as static ESM modules - and dynamic CJS modules are identically inscrutable as dynamic ESM modules.

[12wrigja]

It looks like you might already be planning breaking changes in #71 - I suppose if this did happen it would end up only being available here?

The difference is that ES modules is a standard now and in general the compiler (along with other build tooling in use) supports them (and does not support commonjs).

I'm not sure how it would be different though; the non-deprecated way to use abstract operations is with a deep link, of which each would only have a default export, so I'm not sure what difference ESM vs CJS would make.

I'm not sure what this means - can you elaborate? What does "deep link" mean?

[ljharb]

Yes, the "exports" field and thus ESM won't be available until v2.0, but I'm not planning that any time soon.

CJS is a standard too, for a much longer time than ESM has been; any compiler that doesn't support it is broken and I'd suggest finding a better one.

What i mean is, you should be importing/requiring paths like es-abstract/2019/IsCallable, not grabbing the IsCallable property off of the es-abstract exported object.

[ljharb]

See #136 for the "exports" field.

Since everything is primarily available via deep exports, there's simply no value from using ESM; in v2, deep imports will be the only option.

[ljharb]

Time has convinced me that shipping native ESM offers precisely zero value, so I'm not likely to do it. ESM can import CJS just fine, and thus, any tool that wants to work with the majority of the JS ecosystem must support CJS.