make javascript package support both esm & commonjs #4199

jharris4 · 2023-03-20T14:27:39Z

No description provided.

jharris4 · 2023-03-20T14:32:37Z

I've created this new smaller PR derived from #4193 but this time as a branch against dev with the git commit signature.

I'm not sure if there is some way to get the CI tests to run against this PR, like they did for the original PR against master branch?

Signed-off-by: Jon Harris <harris.jb@gmail.com>

jharris4 · 2023-03-21T08:21:26Z

I fixed the conflicts with dev branch on this PR, and tests are all passing now, except for some failures on cpp-builds for gcc. I don't think that's related to this PR though...?

Signed-off-by: Jon Harris <harris.jb@gmail.com>

ericvergnaud · 2023-03-21T17:03:56Z

runtime-testsuite/resources/org/antlr/v4/test/runtime/helpers/package_ts.json

    "@types/node": "^18.0.5"
-   },
-  "dependencies": {


I believe the dependency is required for 'npm link antlr4' to succeed

nope, all the tests passed without it. You don't need to actually have a package installed to link it. If that were the case nobody would be able to link packages that weren't published first... :-)

that's not my experience at all
it doesn't need to be installed but it has to be declared

The tests are all passing without it, and I use it all the time without first installing, so I guess we have different experiences here :-)

well it's not like having it breaks anything does it ?

ericvergnaud · 2023-03-21T17:07:47Z

runtime/JavaScript/src/antlr4/index.web.js

@@ -8,7 +8,6 @@ import { default as context } from './context/index.js';
 import { default as misc } from './misc/index.js';
 import { default as tree } from './tree/index.js';
 import { default as error } from './error/index.js';
-import { default as CharStreams } from './CharStreams.js';


Why on earth would you want to remove this ?

It has a dependency on FileStream which is node only, so the web version needs to have this removed.

CharStreams.fromString is the recommended constructor, so another solution needs to be identified

it won't work outside of node in any case, so that's outside of the scope of this PR I'd say.

this PR won't make it if it removes functionality

This is removing a node dependency from a web index, I don't know what to say. Can you explain how you want to keep node dependencies working outside of node?

I just pushed a commit just now to address this point. There is now a CharStreams.web.js file that is a copy of the node version but with the nodejs fs specific code removed.

No functionality is removed by this PR anymore.

You're duplicating code. CharStreams.node.js should reuse the code from CharStreams.web.js, adding the 2 file related entry points.

ok, I can make that change. I duplicated code because it followed the pattern of what was done for the index.node.js and index.web.js split.

If we want to keep the code base consistent, doesn't this also mean that the same should be done to the two index files to remove duplication? There is quite a hefty amount of duplication there, and in the type definitions too.

If you can accept this duplication temporarily, I think it might be better to open a separate PR if/after this PR is merged to remove duplication in all places. It'd help limit the scope of this PR, do you agree? :-)

runtime/JavaScript/package.json

ericvergnaud · 2023-03-21T17:10:26Z

runtime/JavaScript/package.json

    "c8": "^7.12.0",
-    "compression-webpack-plugin": "^10.0.0",


so what happens to compression ?

compression doesn't really make sense here. Webpack is used for shipping web applications primarily, and this project is a library... In any case, this only impacts the umd bundle, which nobody really uses.

why build umd if 'nobody really uses it' ? And what makes you think that antlr is not used in web apps ? I do.

we can remove the umd if you'd like. I basically only left it there because it was there before and I was trying to minimize the changes in this PR.

I created this whole PR since we are using antlr4 on the web, so trust me I know how it's used, and this PR is designed specifically to make antlr4 less painful to consume in a web application by correctly setting up the type, main, module & exports fields.

there was no umd before, so not sure I follow...

the bundle you used to create with webpack was also in umd format

internally, but exposed as esm

I'm referring to this umd formatted build output that was pointed to by the package.json browser field.

ericvergnaud · 2023-03-21T17:13:36Z

runtime/JavaScript/package.json

@@ -1,12 +1,26 @@
 {
  "name": "antlr4",
  "version": "4.12.0",
-  "type": "module",


are you proposing to no longer build a module ?

No, the type module is now only in the es directory. Previously this library wasn't actually exporting a module (webpack doesn't output esm modules) but said it was. That was part the motivation of this PR, this kind of stuff breaks builds for other libraries that are consuming antlr4.

Now this package will export both commonjs & esm and support both.

ericvergnaud · 2023-03-21T17:22:41Z

Hi,
thanks for this.
Not sure what problem you are solving...
commonjs and umd are dead, the new standard is esm
the generated parsers are also targeting esm
why are cjs and umd needed when apps can simply consume the esm module ?

jharris4 · 2023-03-21T18:01:09Z

@ericvergnaud thanks for the review comments, happy to address or discuss further if that'll help move this PR forward. :-)

ericvergnaud · 2023-03-21T18:13:52Z

@ericvergnaud thanks for the review comments, happy to address or discuss further if that'll help move this PR forward. :-)

Well you'd have to explain what problem you are solving, with a concrete example. 'Conforming to standards' is not a compelling reason for changing the build when those standards are legacy and tripling the maintenance required to keep it working in the future is definitely a show stopper...

jharris4 · 2023-03-21T18:18:25Z

The problem I'm solving is that we maintain an editor library for the front-end that uses antlr4 for the grammar.

Recently antlr4 changed (in minor version change no less!) from exporting an esm module, to now in the latest version exporting commonjs but saying it's an esm module.

We also have lots of unit tests on our project that use node require for antlr, whereas the frontend apps use esm imports. It's been whack a mole lately trying to fix one or the other.

Suffice it to say, I got tired of working around this, and figured I was better to contributed back a proper fix and help this project get its JavaScript library using best practices for bundling.

TLDR I don't want to care about bundling, and my goal here is for nobody else to have to care about want bundle antlr is exporting either. With this PR, both commonjs & esm are supported.

If you look carefully, you'll see that in fact the JS tests are now using esm, and the TS tests are still using commonjs because of the tsconfig telling it to here:

antlr4/runtime-testsuite/resources/org/antlr/v4/test/runtime/helpers/tsconfig.json

Line 4 in 8dcc652

"moduleResolution": "node",

jharris4 · 2023-03-21T18:23:54Z

Ok, that's a bit of hyperbole saying this PR "triples the maintenance". I put a lot of my own hard (unpaid) work into this, and I spent quite a few hours cleaning things up to try to make it better & easier to maintain. If I failed in that task, it'd be good if you could share specifics.

Signed-off-by: Jon Harris <harris.jb@gmail.com>

ericvergnaud · 2023-03-21T21:42:20Z

not sure where you take it that the current build exports a commonjs module when it actually uses esm imports, doesn't tolerate require and doesn't work at all if you remove "type : module"...

ericvergnaud · 2023-03-21T21:43:48Z

re versioning, the readme tells you that antlr can't follow semver practice. And it didn't change from esm to cjs, rather it got webpacked IIRC.

ericvergnaud · 2023-03-21T21:44:48Z

so you're telling me that something is not working as expected from an esm module, and your 'fix' is to make antlr available as a cjs one ?

ericvergnaud · 2023-03-21T21:47:36Z

the reason I say "triple maintenance" is because from the number of attempts you've been through I can anticipate how much pain it's going to be each time anything changes in the tools involved in the build chain. With 1 build chain it's already a pain, you're proposing to have 3, 1 for each module type...

ericvergnaud · 2023-03-21T21:49:20Z

how about just fixing whatever you think is wrong in esm, and updating your tests to use esm too ?

ericvergnaud · 2023-03-21T21:50:21Z

I have plenty of esm stuff using the esm build (that you say is commonjs) and it works like a charm.
So maybe you need to provide examples of what exactly is not working as expected ?

ericvergnaud · 2023-03-21T21:55:38Z

I also get the feeling that the problems you encounter relate to your specific situation where the front-end is esm but the back-end is cjs ? or is it the front-end tests ?

jharris4 · 2023-03-22T11:06:01Z

As for the motivation of this PR, I offered to have a chat to discuss the motivation & reasoning behind all these changes. A code walkthrough could really help with that, but here we are in text...

Some backstory:

We maintain Neo4j's Cypher editor, which uses an antlr4 grammar behind the scenes, and is consumed in both esm & commonjs format (we don't get to decide what our users use esm or cjs)
A bunch of users have been complaining to us that their builds break in weird unexpected places like when trying to use the editor in test framework that run in node.
I did some investigation and pinpointed the issue to this library, and decided I'd do the right thing and make a PR instead of just forking it.
We also had issues where we couldn't use antlr4 in web context without build errors and weird workarounds to silence those errors.

As per your comments about lots of commits getting this working, YOU SURE ARE RIGHT! :-)

The actual changes for this PR were mostly done by me in about 20 minutes, and the rest of the time & commits was understanding tests & fixing them since I couldn't see how to run them locally.

This PR also makes an improvement in that the JavaScript platform test now uses the code that is published to npm instead of just the source, which is a better practice.

I'd prefer to see that this PR LESSENS the maintenance burden because it's bringing the JavaScript library's build system more in line with best practices as well as fixing some issues.

If you'd like to see the kind of thing this PR is trying to solve, here's an example of the kind of workaround we'd like to stop using to be able to use this repository:

https://github.com/neo4j/cypher-editor/blob/main/packages/antlr4-browser/src/index.js

TLDR on above example, without this we can't use antlr4 for the web. So please don't assume I'm inventing problems here that don't exist.

Believe me I'd very much like to be able to not think about it again, but if it'd be helpful, I'd be happy to help maintain the JS build on this package.

jharris4 · 2023-03-22T11:20:17Z

Also, FYI unkpg can be really useful for examining package build output.

For example here is the current main entrypoint for antrl4:

https://unpkg.com/browse/antlr4@4.12.0/dist/antlr4.node.js

You can see from the above (which is the build output from the JavaScript package) that the code is not pure esm. it's some weird webpack generated thing that imports the require function from a node module...

ericvergnaud · 2023-03-22T13:22:09Z

The current build follows official webpack practice for esm modules, taken from here:
https://webpack.js.org/guides/ecma-script-modules/
So not sure where you take it that it's not esm...
Yes webpack does replace imports with __require, but that thing doesn't come from node, it's 100% local (which is the whole purpose of webpack).
And a consumer can still write: import { x, y } from 'antlr4'; and is required to use import rather than require.
So it is exposed as an esm package.

AFAIK the build works fine for both node and web, thanks to webpack's multi-module feature.
The dependency on FileStream is dropped as part of webpacking, and there is no need to drop CharStreams to achieve that (obviously CharStreams.fromFile will throw). This has been tested successfully with both node and browsers in esm apps.

I understand that you have a specific need to generate a commonjs library, not just an esm one.
You still haven't provided concrete examples of what doesn't work when using the webpack build. https://github.com/neo4j/cypher-editor/blob/main/packages/antlr4-browser/src/index.js gives me no clue re what breaks for your users. All I see is it doesn't export FileStream and CharStreams.

I'd welcome a cjs build but it can't be at the cost of breaking the simplicity of the current build and dropping features or compression.

Since cjs is dead anyway, why not stick to your currently working solution (antlr4-browser) until you no longer need to ship cjs ?

jharris4 · 2023-03-22T15:05:33Z

I understand webpack quite well, I've contributed complex PRs to it, and I maintain a popular open source plugin for webpack to help with deploying web apps. :-)

That said, webpack has web in its name for a reason: it's primary purpose is for building web applications, not libraries. There's a reason pretty much no other npm library package uses it for builds. Tools like babel & rollup are better suited & designed for that purpose. This isn't just my opinion btw.

What tools like webpack (or vite) are VERY good at, is when you are building a web application they scan libraries in node_modules and optimize their bundling if possible (using techniques like tree shaking for esm mode).

For this optimized bundling to work properly, library packages should have main / module or exports properties properly setup in their package.json, and crucially these need to point to either commonjs output or pure esm output.

Currently, the antlr4 package only has this:

{
  "main": "points to nodejs specific entry point that is an es a module but not pure esm",
  "browser": "points to a umd build entry point"
}

And with this PR it now will have this:

{
  "main": "points to web cjs entry point",
  "module": "points to web pure esm entry point",
  "exports": {
    "node": "points to nodejs pure esm entry point",
    "require": "points to web cjs entry point",
    "import": "points to web pure esm entry point"
  }
}

If this package wants to be consumable by both node and web, there is no other documented way to make this work that I'm aware of.

As for commonjs support. Believe me, I would LOVE to move into a world where it's not needed anymore. The trouble is, we are maintaining packages for OTHERS to use. For example with our cypher editor, we have users who are still using commonjs so we can't drop support yet unfortunately.

In general, if you look at any major package published to npm for use in the web right now, you'll see they all provide both cjs & esm entry points to try and play nice with people who are consuming them in their builds.

I'm interested to hear more about This has been tested successfully with both node and browsers in esm apps.. Could you point me to an example of antlr4 being used in a web context?

Signed-off-by: Jon Harris <harris.jb@gmail.com>

jharris4 · 2023-03-22T20:58:02Z

Those imports are bringing in the entire default import, so it's not just the Lexer, it's all the functionality a consuming web library such as our cypher editor needs. So the savings are considerable!

But in any case, it seems like we're reaching the end of the road here. I feel it's a shame that my hard work and commitment to making things better wasn't better received, but I guess part of that is on me for failing to make the case for why this PR is more than just a spurious improvement.

In any case, I guess it's not a total waste since I now see an upgrade path for us from 4.10.1 to 4.12.0 that unblocks us, we just have to accept that the esm for antlr4 isn't really esm, and accept the extra couple of hundred KB bundle size increase as unavoidable.

Thanks for all your great work on this library, I really do appreciate that it builds properly for node & web now in the latest versions thanks to your improvements.

If you want to discuss this PR further I'd be happy to, but I also understand if you'd just rather stick with stuff you're comfortable with.

ericvergnaud · 2023-03-23T18:11:07Z

Indeed, thanks for your efforts. Please close.

jharris4 · 2023-03-23T19:04:57Z

ok closing, it'll be around as a reference for anyone else who wants to look into this stuff :-)

I'd consider making another PR to just fix the esm exports (without adding cjs), if there's any interest in having a fix for that merged.

If this library is open to that possibility let me know, otherwise I won't spend the effort.

NilsBaumgartner1994 · 2023-03-26T17:55:30Z

stuck at the same problem currently:

const antlr4 = require('antlr4');
//import antlr4 from 'antlr4';

async function main() {
  new antlr4.InputStream("Hallo");

internal/modules/cjs/loader.js:1080
      throw new ERR_REQUIRE_ESM(filename, parentPath, packageJsonPath);
      ^

Error [ERR_REQUIRE_ESM]: Must use import to load ES Module: /Users/nbaumgartner/Documents/GitHub/data-clumps/src/api/node_modules/antlr4/dist/antlr4.web.js
require() of ES modules is not supported.
require() of /Users/nbaumgartner/Documents/GitHub/data-clumps/src/api/node_modules/antlr4/dist/antlr4.web.js from /Users/nbaumgartner/Documents/GitHub/data-clumps/src/api/build/ignoreCoverage/development.js is an ES module file as it is a .js file whose nearest parent package.json contains "type": "module" which defines all .js files in that package scope as ES modules.
Instead rename antlr4.web.js to end in .cjs, change the requiring code to use import(), or remove "type": "module" from /Users/nbaumgartner/Documents/GitHub/data-clumps/src/api/node_modules/antlr4/package.json.

    at Object.Module._extensions..js (internal/modules/cjs/loader.js:1080:13)
    at Module.load (internal/modules/cjs/loader.js:928:32)
    at Function.Module._load (internal/modules/cjs/loader.js:769:14)
    at Module.require (internal/modules/cjs/loader.js:952:19)
    at require (internal/modules/cjs/helpers.js:88:18)
    at Object.<anonymous> (/Users/nbaumgartner/Documents/GitHub/data-clumps/src/api/build/ignoreCoverage/development.js:14:16)
    at Module._compile (internal/modules/cjs/loader.js:1063:30)
    at Object.Module._extensions..js (internal/modules/cjs/loader.js:1092:10)
    at Module.load (internal/modules/cjs/loader.js:928:32)
    at Function.Module._load (internal/modules/cjs/loader.js:769:14) {
  code: 'ERR_REQUIRE_ESM'
}

NilsBaumgartner1994 · 2023-03-27T13:58:28Z

Out of the box

Unfortunately this only works for react apps but not for plain node projects.

Following this simple tutorial to create a npm package: https://itnext.io/step-by-step-building-and-publishing-an-npm-typescript-package-44fe7164964c

And having this simple "index.ts" file:

const antlr4 = require('antlr4');
const input = "Hello, world!";
const chars = new antlr4.InputStream(input);

export const Greeter = (name: string) => `Hello ${name}`;

results in the same error.

ericvergnaud · 2023-03-27T14:33:36Z

Why don't you use import { InputStream } from 'antlr4' ?

NilsBaumgartner1994 · 2023-03-27T15:11:48Z

Why don't you use import { InputStream } from 'antlr4' ?

Because it still show the same error. Would be realy nice if antlr4 would support this as mentioned in this PR.

internal/modules/cjs/loader.js:1080
      throw new ERR_REQUIRE_ESM(filename, parentPath, packageJsonPath);
      ^

Error [ERR_REQUIRE_ESM]: Must use import to load ES Module: /Users/nbaumgartner/Documents/GitHub/Playground/node_modules/antlr4/dist/antlr4.node.js
require() of ES modules is not supported.
require() of /Users/nbaumgartner/Documents/GitHub/Playground/node_modules/antlr4/dist/antlr4.node.js from /Users/nbaumgartner/Documents/GitHub/Playground/lib/index.js is an ES module file as it is a .js file whose nearest parent package.json contains "type": "module" which defines all .js files in that package scope as ES modules.
Instead rename antlr4.node.js to end in .cjs, change the requiring code to use import(), or remove "type": "module" from /Users/nbaumgartner/Documents/GitHub/Playground/node_modules/antlr4/package.json.

    at Object.Module._extensions..js (internal/modules/cjs/loader.js:1080:13)
    at Module.load (internal/modules/cjs/loader.js:928:32)
    at Function.Module._load (internal/modules/cjs/loader.js:769:14)
    at Module.require (internal/modules/cjs/loader.js:952:19)
    at require (internal/modules/cjs/helpers.js:88:18)
    at Object.<anonymous> (/Users/nbaumgartner/Documents/GitHub/Playground/lib/index.js:4:16)
    at Module._compile (internal/modules/cjs/loader.js:1063:30)
    at Object.Module._extensions..js (internal/modules/cjs/loader.js:1092:10)
    at Module.load (internal/modules/cjs/loader.js:928:32)
    at Function.Module._load (internal/modules/cjs/loader.js:769:14) {
  code: 'ERR_REQUIRE_ESM'
}

I will check your other comment

Your package must be configured for ESM. Check this: https://gist.github.com/sindresorhus/a39789f98801d908bbc7ff3ecc99d99c

jharris4 · 2023-03-27T15:47:31Z

Yeah, this example is trying to use commonjs node module resolution to import antlr4 which afaik just won't work since it currently has "type": "module" in the package.json.

This PR fixes the above error (and makes the esm build sizes smaller too), but I seem to have done a poor job explaining why the fix was important enough to be merged.

I wish we were in a pure esm world where we could get rid of commonjs, but too many of our consumers are still using commonjs for us to make that choice for them. It's a tough sell telling them they have to go modernize all their JavaScript to esm from cjs just to use our code, but without this PR we don't seem to have any other options.

It's so strange to hate commonjs and want to get rid of it, and be here trying to argue for it's inclusion in a PR, but here we are! haha

NilsBaumgartner1994 · 2023-03-27T15:55:39Z

Yeah, this example is trying to use commonjs node module resolution to import antlr4 which afaik just won't work since it currently has "type": "module" in the package.json.

This PR fixes the above error (and makes the esm build sizes smaller too), but I seem to have done a poor job explaining why the fix was important enough to be merged.

I wish we were in a pure esm world where we could get rid of commonjs, but too many of our consumers are still using commonjs for us to make that choice for them. It's a tough sell telling them they have to go modernize all their JavaScript to esm from cjs just to use our code, but without this PR we don't seem to have any other options.

It's so strange to hate commonjs and want to get rid of it, and be here trying to argue for it's inclusion in a PR, but here we are! haha

I think transitioning to modern projects is good. But I think what would help here would be for people a clean small example package. For me I want to develop a npm package which has typescript and can be imported and used in other projects like react-native. Therefore the building process was a bit hard and to have a possibility to test my package. This makes transitions easier if you have a MWP (minimal working project).

ericvergnaud · 2023-03-27T16:10:55Z

Feel free to propose a sample MWP that can be downloaded from the docs.

NilsBaumgartner1994 · 2023-03-27T16:24:05Z

Trying to make it work

NilsBaumgartner1994 · 2023-03-30T09:06:56Z

Can use antlr4 in directus because of esm package: directus/directus#17997

NilsBaumgartner1994 · 2023-03-30T10:38:57Z

@jharris4 trying out your npm package for antlr4 since i hope it will solve my problem. Unfortunately it has no documentation yet ;-) But i believe that should be easy doable.

NilsBaumgartner1994 · 2023-03-30T10:42:44Z

@jharris4 Your package works like a charm <3 Your points are exaclty correct.

As for commonjs support. Believe me, I would LOVE to move into a world where it's not needed anymore. The trouble is, we are maintaining packages for OTHERS to use. For example with our cypher editor, we have users who are still using commonjs so we can't drop support yet unfortunately.

That is so 100% true.

@ericvergnaud I hope you guys see that this is a real need :-) I love antlr4 since it is very powerful.

NilsBaumgartner1994 · 2023-03-30T10:44:52Z

antlr-js-exports

For all out there facing a similar problem this package could help from @jharris4

jharris4 · 2023-03-30T12:18:50Z

@NilsBaumgartner1994 thanks for confirming the fix in the forked package, but please note that package was purely for testing, and not recommended for real world usage.

People should stick with the official antlr4 package with the caveat that there's no support for commonjs module resolution.

NilsBaumgartner1994 · 2023-03-30T15:01:37Z

Hi there, Sure but as you said, it shows that the fix works.Beste Grüße,Nils BaumgartnerAm 30.03.2023 um 14:19 schrieb Jon Harris ***@***.***>: @NilsBaumgartner1994 thanks for confirming the fix in the forked package, but please note that package was purely for testing, and not recommended for real world usage. People should stick with the official antlr4 package with the caveat that there's no support for commonjs module resolution. —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: ***@***.***>

NilsBaumgartner1994 · 2023-03-30T15:02:00Z

Looking forward to official antlr4 support.Beste Grüße,Nils BaumgartnerAm 30.03.2023 um 14:19 schrieb Jon Harris ***@***.***>: @NilsBaumgartner1994 thanks for confirming the fix in the forked package, but please note that package was purely for testing, and not recommended for real world usage. People should stick with the official antlr4 package with the caveat that there's no support for commonjs module resolution. —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: ***@***.***>

antoniom · 2023-03-31T12:09:34Z

We have a similar problem:

Our frontend application (written in TS) is using @reduxjs/toolkit and other dependencies which are not available as ESM.
Upgrading antlr to 4.12 causes tests that use the package to fail. To fix them I followed Jest's guide on testing ESM modules which caused tests that were using non-ESM modules to fail from their side.

NilsBaumgartner1994 · 2023-03-31T12:45:26Z

Which antlr4 version did you used prior?Beste Grüße,Nils BaumgartnerAm 31.03.2023 um 14:09 schrieb Antonis Balasas ***@***.***>: We have a similar problem: Our frontend application (written in TS) is using @reduxjs/toolkit and other dependencies which are not available as ESM. Upgrading antlr to 4.12 causes tests that use the package to fail. To fix them I followed Jest's guide on testing ESM modules which caused tests that were using non-ESM modules to fail from their side. —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: ***@***.***>

antoniom · 2023-03-31T14:32:46Z

@NilsBaumgartner1994 using 4.8.0 using js/babel, no TS

ericvergnaud · 2023-03-31T15:23:10Z

Please move this to the CommonJS support discussion

ericvergnaud · 2023-04-02T10:20:17Z

@antoniom @NilsBaumgartner1994 please check #4217

ericvergnaud · 2023-04-02T10:20:43Z

@jharris4 please check #4217

JohnDoeAntler · 2023-05-20T14:40:35Z

@jharris4 You're my lifesaver, thanks for your NPM package! I was spending half a day trying to get the ANTLR4 runtime running without the ESM error, then I saw the comment from @NilsBaumgartner1994, just in a half minute of installing the package then I got rid all issues! :D

NilsBaumgartner1994 · 2023-05-20T15:16:56Z

@jharris4 You're my lifesaver, thanks for your NPM package! I was spending half a day trying to get the ANTLR4 runtime running without the ESM error, then I saw the comment from @NilsBaumgartner1994, just in a half minute of installing the package then I got rid all issues! :D

You're welcome :-) looking forward for official support as this is a thing more people need.

jharris4 mentioned this pull request Mar 20, 2023

Improve JS build to better support esmodules/commonjs/node #4193

Closed

make javascript package support both esm & commonjs

c926ca3

Signed-off-by: Jon Harris <harris.jb@gmail.com>

jharris4 force-pushed the esm-commonjs branch from 1b8cd67 to c926ca3 Compare March 20, 2023 19:43

make clean scripts work on windows by using del-cli

a38893e

Signed-off-by: Jon Harris <harris.jb@gmail.com>

ericvergnaud reviewed Mar 21, 2023

View reviewed changes

runtime/JavaScript/package.json Outdated Show resolved Hide resolved

ericvergnaud reviewed Mar 21, 2023

View reviewed changes

runtime/JavaScript/package.json Outdated Show resolved Hide resolved

ericvergnaud reviewed Mar 21, 2023

View reviewed changes

rename directories lib -> cjs and es -> esm

c7a230b

Signed-off-by: Jon Harris <harris.jb@gmail.com>

add CharStreams.web.js & .d.ts with no fs usage

81dc0f9

Signed-off-by: Jon Harris <harris.jb@gmail.com>

jharris4 closed this Mar 23, 2023

NilsBaumgartner1994 mentioned this pull request Mar 27, 2023

Error: Npm package, plain Node: ERR_REQUIRE_ESM #4208

Closed

3 tasks

NilsBaumgartner1994 mentioned this pull request Mar 30, 2023

ESM Package directus/directus#17997

Closed

jharris4 mentioned this pull request May 10, 2023

Revisit antlr4 dependency once they fix their packaging neo4j/cypher-editor#132

Open

make javascript package support both esm & commonjs #4199

make javascript package support both esm & commonjs #4199

Conversation

jharris4 commented Mar 20, 2023

jharris4 commented Mar 20, 2023

jharris4 commented Mar 21, 2023

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ericvergnaud commented Mar 21, 2023

jharris4 commented Mar 21, 2023

ericvergnaud commented Mar 21, 2023

jharris4 commented Mar 21, 2023

jharris4 commented Mar 21, 2023

ericvergnaud commented Mar 21, 2023

ericvergnaud commented Mar 21, 2023 • edited Loading

ericvergnaud commented Mar 21, 2023

ericvergnaud commented Mar 21, 2023

ericvergnaud commented Mar 21, 2023

ericvergnaud commented Mar 21, 2023

ericvergnaud commented Mar 21, 2023 • edited Loading

jharris4 commented Mar 22, 2023

jharris4 commented Mar 22, 2023

ericvergnaud commented Mar 22, 2023

jharris4 commented Mar 22, 2023

jharris4 commented Mar 22, 2023

ericvergnaud commented Mar 23, 2023

jharris4 commented Mar 23, 2023

NilsBaumgartner1994 commented Mar 26, 2023

NilsBaumgartner1994 commented Mar 27, 2023

ericvergnaud commented Mar 27, 2023

NilsBaumgartner1994 commented Mar 27, 2023

jharris4 commented Mar 27, 2023

NilsBaumgartner1994 commented Mar 27, 2023

ericvergnaud commented Mar 27, 2023

NilsBaumgartner1994 commented Mar 27, 2023

NilsBaumgartner1994 commented Mar 30, 2023

NilsBaumgartner1994 commented Mar 30, 2023

NilsBaumgartner1994 commented Mar 30, 2023

NilsBaumgartner1994 commented Mar 30, 2023

jharris4 commented Mar 30, 2023

NilsBaumgartner1994 commented Mar 30, 2023 via email

NilsBaumgartner1994 commented Mar 30, 2023 via email

antoniom commented Mar 31, 2023

NilsBaumgartner1994 commented Mar 31, 2023 via email

antoniom commented Mar 31, 2023

ericvergnaud commented Mar 31, 2023 • edited Loading

ericvergnaud commented Apr 2, 2023

ericvergnaud commented Apr 2, 2023

JohnDoeAntler commented May 20, 2023

NilsBaumgartner1994 commented May 20, 2023

ericvergnaud commented Mar 21, 2023 •

edited

Loading

ericvergnaud commented Mar 21, 2023 •

edited

Loading

ericvergnaud commented Mar 31, 2023 •

edited

Loading