AssertionError when calling edtf("{1978,1988}") in prod about edtf.js

[inukshuk]

I can't reproduce this, so I'd follow-up on the idea that this is related to a bundling issue. Ideally, you should be able to just import from 'edtf' but if your bundler does not support package entry points it would fallback to the Common JS version -- I suspect this is what happened for your (in this case you can still access the same functionality via edtf.parse) but I'd make sure to configure your bundler so that you that 'edtf' resolves to the correct entry point for ES modules.

Otherwise, if you want to debug this in the bundled code, I'd suggest to either disable minification so that you can use the debugger, or else insert some log statements particularly around here in order to figure out what's going on. You see that the constructors are mapped to type names, so this is something where an issue code-obfuscation might come into play.

[berger-n]

thanks for the answer

I was hoping using edtf.parse could work but it doesn't because edtf is considered a string with value /static/media/index.cdefe064.cjs, not an object, when I use import edtf from "edtf" (what you mean by fallback to Common JS version I guess)

make sure to configure your bundler so that you that 'edtf' resolves to the correct entry point for ES modules

I'm sorry but I'm not sure to understand what is implied here, could you explain a bit more please?

[inukshuk]

What I mean is that you should first make sure that import edtf, { parse } from 'edtf' works as expected. This module is a native ES module which includes a Common JS fallback. The fallback is at ./dist/index.cjs and created using Rollup; the default entry point ./index.js is the ES module.

When you import from 'edtf' in your code, the first question is which of the two modules your bundler loads. In theory, it could resolve to the Common JS module and convert it to ESM for use in your code or it could use ESM directly -- it would be important to know which one it is to debug the issue further. The bundler reported that 'parse' is not exported by the module, so the question is which module did it look at and why does it think that parse is not being exported? If it's looking at the ESM module, the export is right here; if it's looking at CJS the export is here. Both of these look fairly straightforward to me, so maybe your bundler is resolving 'edtf' to something else entirely? Anyway, that's where I'd start. Once you're sure that the bundler is actually loading the right thing the next question is why and how it breaks the module later on.

[berger-n]

thanks a lot for your help!

found this in main.chunk.js

var edtf__WEBPACK_IMPORTED_MODULE_2__ = __webpack_require__(/*! edtf */ "./node_modules/edtf/dist/index.cjs");

so the first answer must be ./node_modules/edtf/dist/index.cjs

what puzzles me most is why import edtf from "edtf" returns the string /static/media/index.cdefe064.cjs?
I didn't know this was even possible I must say

[inukshuk]

Right, so Webpack seems to pick the CJS module for you. I wonder if this is intentional? In any case, what happens when you write import edtf from 'edtf' in your code depends on how exactly Webpack exposes this CJS module to your ESM code. From the above I would guess that Webpack creates some kind of proxy module where the default export is a string to bundled CJS module.

In any case, you need to find out (or decide) how this should be handled by your setup in general. Do you prefer to pull in native ESM modules (in this case you need find out how to tell Webpack to load the appropriate module) or CJS modules which are converted to ESM (in this case you need to know how the conversion works, because it affects the way the module is exposed to your code).

[berger-n]

I think I'm more interested in

find out how to tell Webpack to load the appropriate [ESM] module

but I can't figure out yet how this can be configured in webpack, is this related https://webpack.js.org/guides/ecma-script-modules/#flagging-modules-as-esm ? yet Named exports are not available so it did not solve my problem (but it did not change that it loads ./node_modules/edtf/dist/index.cjs instead of ./node_modules/edtf/index.js... so that may not be what you were talking about above)

thanks again for your help

[inukshuk]

Yes, I agree that it should be preferred to have Webpack pull in the ESM module. edtf.js identifies as an ESM module by setting the package type. However, it's a dual-module with multiple entry points, defined by 'export' as I've linked to earlier. I think what happens is that Webpack uses the 'main' property which points to a .cjs file -- the file extension overrides the fact that the entire module is defined as ESM. However, 'main' is only there as a fallback: if a module loader supports 'export' it's supposed to ignore 'main'. To me it looks like Webpack does not support this feature, and therefore loads the fallback CJS module. If that's the case you can probably work around it in the webpack config with some kind of override that instructs it to load 'edtf/index.js' instead.

[inukshuk]

Or perhaps there is a Webpack plugin or config setting which enables support for Node's package entry points.

[berger-n]

looks like "main" entry point is preferred to "exports"
indeed I can load edtf as an ESM module when I remove this line from package.json
for typescript to run I also had to add an index.d.ts with content declare module 'edtf'; at the root of edtf module directory
all of which solved the first problem! thanks a lot

var edtf__WEBPACK_IMPORTED_MODULE_1__ = __webpack_require__(/*! edtf */ "./node_modules/edtf/index.js");

unfortunately the initial issue still occurs when module properly loaded as ESM
but thanks to your suggestion I was able to track down where exactly it fails:

edtf.js/src/list.js

Line 31 in 988e2eb

if (obj.type) assert.equal(this.type, obj.type)

see screenshots below, output shown is that of current args and typeof of its content, then values of both arguments of assert:

• when running app in dev mode:

• when running built app:

hope this helps!

[inukshuk]

OK so if I understand your screenshots correctly, this.type in the List constructor (right before the assert) returns 'n'?

If hat's the case then it's possible that you're renaming the class name when building the app. this.type should evaluate to this.constructor.name -- in the context of the List constructor this should return 'List' unless the List class has been renamed

[berger-n]

issue was due to webpack minimizer renaming classnames
I forked your repo and made minor changes
now everything's fine in our app
thanks again for your help!

[bdarcus]

Is there any reason why not to add the typescript declaration file here, @berger-n? E.g. a PR?

I'm seeing the same error.

EDIT: nevermind; it's just a line.

[berger-n]

@bdarcus indeed, for the record we mostly had a bunch of fixes that were very specific to our toolchain:
main...buda-base:edtf.js:main