Bring random-js back up to speed with newer webpack and node

[rawr51919]

All dependencies have been updated to their latest versions, linter errors have been fixed, build errors in webpack 5+ have been fixed, there are many things that have changed (even the author's credit got updated to her correct name, she is Summer now).
One unfortunate side effect of the updates is that ES3 support is dropped. @ckknight please let me know if there are any more things you want me to do before this gets merged, I'm sure I got everything covered.

Things left to do in this PR:

• Add support for automatic dependency updates and automerging now and in the future using Mend Renovate (configuration is already in this PR, @ckknight will need to do some work on her end to enable this, namely adding the integration for Renovate to this repository and mayhaps her account too: https://github.com/apps/renovate) (once done, this will fix Automatic dependency updates #66)
• Rewire the build so it runs on GitHub Actions instead (fixing Converting the build to GitHub Actions #67)
• Add support for React Native (fixing Enable better ESM compatibility #45 and feat: Add support for React Native #40)
• Include '.js' in imports (fixes Include ".js" in imports #35) (May not be possible to fix this one due to rollup complaining about it)
• Add min and max commands (fixing Force value to either min or max #42)
• Add support for automatically choosing the best engine for platform being used (fixing Choose "best" engine automatically? #43) (As of this PR, this can be achieved through const random = Random.auto();)
• Add documentation on using this library without Node and with Webpack 5+ (fixing Add documentation on how to use this library without Node.js and/or with Webpack 5+ #69 (nice), and var random = new Random.Random() does not work when random-js is imported as a script #59)
• Better documentation on making custom engines that interface with this library (fixing Better documentation on how to create custom engines in README.md #68 and potentially paving the way for fixing Add new engine based on Richard Brent's xorgens-4096 PRNG #19)
• (ties into the above, secondary objective) Build a xorgens-4096 PRNG for this engine (fixing Add new engine based on Richard Brent's xorgens-4096 PRNG #19)
• Documentation on how to replicate Math.random() using this engine (fixing Question: replicating exact functionality of Math.random() #38)
• Better documentation on why randomInt() is biased (fixing More information about randomInt being biased? #13 using info from More information about randomInt being biased? #13 (comment) and helping better explain why a library like this one is necessary)
• Fix all warnings in npm test (secondary objective yet will be a lot cleaner when tests are run)
• Add documentation about random-js-no-node and link to it somewhere in the README
• Fix minor typos and documentation errors contained in various PRs (PRs Update README.md #64 (courtesy of @aaby242abhay), fixed some type in random.ts #55 (courtesy of @MohammadXroid), small fix in README.md #33 (courtesy of @pgerlach), and Add CDNJS version badge in readme #22 (courtesy of @kennynaoh))

Fixes #69
Fixes #68
Fixes #67
Fixes #64
Closes #63
Closes #62
Closes #61
Closes #60
Fixes #59
Closes #58
Closes #57
Closes #56
Fixes #55
Closes #54
Closes #53
Closes #52
Closes #50
Closes #49
Closes #48
Closes #46
Closes #45
Fixes #43
Fixes #42
Fixes #40
Closes #39
Fixes #38
Closes #35
Fixes #33
Fixes #22
Fixes #13

[ckknight]

Oh wow, thanks for this!

ES3 support is dropped

I'm really not sure if I care in 2023

the author's credit got updated to her correct name

You're a gem 💎

---

I'll take a further look this weekend and hopefully merge this in, as long as it doesn't introduce any unexpected breakages.

A large part of me wants to revamp the entire package, or split it into multiple pieces, or some other mechanism to make sure it's as easy as possible to tree-shake.

The best approach for that is probably to spruce it up while keeping it the same (read: this PR), then make decisions from there.

[rawr51919]

About the only thing left would be to implement #64, #55, #33, and #22, then all of random-js will be up to speed entirely

Will also be fixing #59, #40, #35, and #13 as a result of this PR, there is a bunch of warnings in 'npm test' I can't seem to figure out yet everything passes otherwise

[rawr51919]

Oh wow, thanks for this!

ES3 support is dropped

I'm really not sure if I care in 2023

the author's credit got updated to her correct name

You're a gem 💎

I'll take a further look this weekend and hopefully merge this in, as long as it doesn't introduce any unexpected breakages.

A large part of me wants to revamp the entire package, or split it into multiple pieces, or some other mechanism to make sure it's as easy as possible to tree-shake.

The best approach for that is probably to spruce it up while keeping it the same (read: this PR), then make decisions from there.

This would likely become a sufficient base for version 3.0
Also, have Dependabot automatically merge dependency updates if the tests pass with the new dependency through either itself or GitHub Actions so the repo doesn't get clogged with dependency update PRs (issue created at #66)
Also the builds should get swapped to GitHub Actions as Travis CI is no longer a truly free build service (issue created at #67)

[rawr51919]

OK, I answered #38 and will try to close it with the merging of this PR once it's all finished

[rawr51919]

@ckknight I'm getting back onto this PR, was kinda hard to think about where to start without putting up a todo list of everything that needs done before it's ready for merge

[rawr51919]

Made sense to convert this to a draft, college work has gotten in the way, I'll be back to work on this hopefully soon

[thejustinwalsh]

This is still relevant in 2025, love this library, realistically what needs to be done to bring this up to date. How can I help?

[rawr51919]

This is still relevant in 2025, love this library, realistically what needs to be done to bring this up to date. How can I help?

Basically look at which things I haven't checkmarked here yet and, if you want to, take a crack at them

[rawr51919]

Big update, sorry for the 2-year-long wait! The Mend Renovate config is ready to use when @ckknight's got it set up here, the xorgens-4096 engine is implemented, builds have been moved to GitHub Actions (and are passing!), the TSLint build step has been migrated to ESLint + full ESM in the Jest config, automatic engine detection has been implemented (use const random = Random.auto(); to use), added documentation on Webpack 5+ polyfills, React Native, and random-js-no-node, and added a new baseline document for adding new RNG engines to random-js.

Almost done, just a few more things left to do and this should be ready to merge.

@ckknight Can you please look through the new changes and tell me if I need to do anything?

[rawr51919]

#35 is unfixable because it causes errors in Rollup when the final build is done after the tests.

Can someone please close that?

[rawr51919]

And with that, ready to test, check, and merge!

@Spacerat Your no-node branch might be serving a purpose now

[Spacerat]

Huh, I totally forgot I did that.

Am I understanding correctly that your docs are now going to point to that branch as the right way to use Random-JS on React Native?

I've not used or updated that branch for a long time - not since I created it. Do you think it’s OK of it remains as it is? I wonder if it makes sense for you to take ownership of it.

[rawr51919]

Huh, I totally forgot I did that.

Am I understanding correctly that your docs are now going to point to that branch as the right way to use Random-JS on React Native?

I've not used or updated that branch for a long time - not since I created it. Do you think it’s OK of it remains as it is? I wonder if it makes sense for you to take ownership of it.

The docs say either way, literally up to you to decide which package to use on React Native.

If you want me to take over the reins of that one I'd be happy to, I'd have to copypasta all the changes made in this PR and send them to that too although that's OK, will be waiting for Summer to merge it here first before the no-node version gets it merged too (or I could wait until this PR gets merged here and then sync the fork to match)

In the process I'd have to strip the rest of the nodeCrypto code completely out of the no-node version to remove unnecessary bloat in that package

Would it even be possible to take over the NPM package for no-node so new packages can be uploaded from my end?