Fraction.js

Fraction.js copied to clipboard

Fraction.js:9 Uncaught TypeError: Object.defineProperty called on non-object at Function.defineProperty () at Fraction.js:9:10 at a (factory.js:35:12) at Object. (pureFunctionsAny.generated.js:22:38) at u ((index):1:2157) at Object. (main.cd1dd74d.chunk.js:1:292368) at u ((index):1:2157) at Object. (main.cd1dd74d.chunk.js:1:115856) at u ((index):1:2157) at Object. (main.cd1dd74d.chunk.js:1:785656) (anonymous) @ Fraction.js:9 a @ factory.js:35 (anonymous) @ pureFunctionsAny.generated.js:22

Looks like https://github.com/josdejong/mathjs/issues/3022 is being reproduced again. I am using mathjs version 11.10.1.

The mathjs was using version 4.3.6. I changed that in yarn.lock file to 4.3.4 then it started working. Since we dont push yarn.lock into server the issue remains in our live app.

"resolutions": { "fraction.js": "4.3.4" },

Adding this in package.json to lock fraction.js version to 4.3.4 worked for me so issue might be in either 4.3.5 or 4.3.6

Are you using the latest webpack version? 4.3.4 restored the old module behavior, but then I tried again to introduce the module setup when I found the issue. Now the setup is how it should be, with proper exports in the package.json for import and require. Do you use import in your project?

Are you using the latest webpack version? 4.3.4 restored the old module behavior, but then I tried again to introduce the module setup when I found the issue. Now the setup is how it should be, with proper exports in the package.json for import and require. Do you use import in your project?

Our webpack version is 4.19.1 and yes we use import in our project

@josdejong @ai-rohit Found it, seems webpack decided to not port back exports to v4: https://github.com/webpack/webpack/issues/9509

Do you have the option to go with v5?

josdejong/mathjs#3022

Sorry, but we can't go with v5 right now. We already have lots of changes in queue.

We have the following conflict and I don't know how to resolve it properly:

• Your old webpack version expects an ESM module in main, while a CJS module is exported there
• Newer webpack versions override main with exports, how it should be
• Older node installments ignore exports and type: "module" so that the default on main should be the CJS file (which caused #67 )

For now I only see the following hacky resolutions for this problem:

• mathjs really decides to version pin to 4.3.4 for some time @josdejong
• you try to deploy the yarn.lock with a local version pinning and upgrade to v5 as soon as possible
• Try the following, if it works, I'll change it in a new fraction.js version:

Go into the node_modules/fraction.js (@4.3.6) folder and open the fraction.cjs file. Go to line 878 and replace the if/else block with the following:

  if (typeof exports === "object") {
    Object.defineProperty(Fraction, "__esModule", { 'value': true });
    Fraction['default'] = Fraction;
    Fraction['Fraction'] = Fraction;
    module['exports'] = Fraction;
  } else {
    root['Fraction'] = Fraction;
  }

We currently deployed locking fraction.js version to 4.3.4. But would like this issue to get resolved soon. We are already working on upgrading webpack but not sure when we will rollout our app with webpack v5.

@infusion do you want me to publish a version of mathjs that uses [email protected] with an exact version number? Or are you working on an other solution?

For the time being I've published [email protected] with [email protected] pinned as exact version number.

I think a neat solution could simply be to publish fraction.js as v5.0.0, and accept that it does not support old setups like Webpack 4 (which was last updated 3 years ago...)?

Thanks for pinning v4.3.4 in mathjs, I think this is a good tmp solution. Measured on the usage counts of Fraction.js, no further complaints came in, so I think the package.json setup behind v4.3.6 is robust now. I'll not revert it for now with a new version. If it occurs more often until we release v5.0.0, I'll push a v4.3.7 with the old v3.4.3 setup.

Then v.5.0.0 will be breaking anyways with BigInt, but I'd be happy if v4 differs only in that feature so far.

I think the package.json setup behind v4.3.6 is robust now

I'm not sure if I understand: v4.3.6 still gave some issues, right? That's why we reverted to v4.3.4. So shouldn't a v4.3.7 be released anyway?

Yes, v4.3.6 makes trouble with webpack v4, since they don't want to backport the the new exports attribute. I think I'll do it like I wrote in your mail, remove the type: "module" again, but with the exports attribute, which would result in a v4.3.7. Then this would be the last version in the v4 regime and based on that v5 introduces BigInt.

So, basically v4.3.7 will be the same as v4.3.4 working in all current cases? Or did you manage to find a solution that works again in all cases?

Yes, plus the exports field for newer installations. This is also how I would treat it with v5 then, which seems to be the way to go atm for hybrid libs.

Not having read the recent comments, here is some of my analysis of examining console output when experimenting with Observable » Martien » Getting require fraction.js to work.

The error occurs when the version numbers in package.json and fraction.cjs do not match. Not sure if this is related and wether this is the cause of the problem.

`// try uncomment each require turn by turn and reload the page // search Console » Sources for "fraction" // examine package.json.version and fraction.cjs

// Fraction = require("fraction.js@4") // unable to load module; // package.json shows 4.3.6 // fraction.js shows 4.3.5

Fraction = require("[email protected]") // works fine // package.json shows 4.0.14 // fraction.js shows 4.0.14

// Fraction = require("fraction.js") // unable to load module; // package.json shows 4.3.6 // fraction.cjs shows 4.3.5 (31/08/2023)?!

// Fraction = require("[email protected]") // unable to load module; // package.json shows 4.3.6 // fraction.cjs shows 4.3.5 (31/08/2023)

// Fraction = require("[email protected]") // unable to load module; // package.json shows 4.3.6 // fraction.cjs shows 4.3.5 (31/08/2023)`

@infusion what are your plans regarding a [email protected]?

If you're planning to breaking release soon I would like to align that with a breaking release that is planned for mathjs, see https://github.com/josdejong/mathjs/issues/3032.

ping @infusion