Localize all vars about esomath.js

[fitiskin]

Just an idea. Perhaps it would be more convenient to organize the library as a npm package? So that all functions would be available without monkey patching, touching globalThis object and expanding native prototypes such as Number or BigInt.

import { Numeric, Float } from 'well-named-enhanced-js-math-library'

or even

import { modPow } from 'well-named-enhanced-js-math-library/math'

It will allow users to safely use the code in their projects without fear of breaking them with a new suddenly adopted ECMAscript standard.

I would help you with package building, refactoring, and so on.

What do you think?

[Rudxain]

I realized this library wouldn't be useless even after removing everything that is not a Stage +1 proposal. I still haven't made the decision about the future of this library. I'll open a new Issue about this

[Rudxain]

For consistency, I decided that the only global values and fns that should be encapsulated/localized, should be everything but prototype methods, because of the call problem (infinite regress), and because using call makes the code less "elegant". So this library will do the assumption that all prototypes are immutable (even if they aren't)

[Rudxain]

@fitiskin I've been considering doing that. This library includes a lot of stuff that would probably never be added to the official ES spec (like Fibonacci, and inverse factorials), so it shouldn't be used as a polyfill, but rather as a standalone library. Another solution is to remove anything/everything that is not strictly and definitely included in a Stage [1, 4] proposal, ensuring there's more safety about using this as a polyfill. All of the removed functions can then be migrated to my "Useless-Math" repo, and then I would turn that into a non-polyfill standalone library distributed using NPM.

Also, IIFE polyfills ensure everything behaves exactly like built-in methods, so using ESM may not be a good idea for this. I need more info to take a better decision about it.

The problem with my "solution" to remove stuff is that the library would become useless very fast, because core-js already has better polyfills for future JS math, but I want this library to add more stuff because it makes it more unique.

Maybe I should completely abandon the polyfill library concept, and just turn this into a normal library. I could still make polyfills for future stuff, but in smaller quantities, which would make it easier to maintain and change, and I could post them as Gists instead of dedicating entire repos to them.

Thank you for your insight, I'll start thinking more about this

[Rudxain]

I've given up on JS, so I'll 🦀RIIR in the future.

I'll keep the JS commit history in a secondary branch, for archiving purposes