std/jspolyfills

[timotheecour]

/cc @juancarlospaco @xflywind how about a stdlib module std/jspolyfills to gather all polyfills in 1 place

links

• globalThis shim nim-lang/Nim#16054
• Make Math.trunc polyfill optional? nim-lang/Nim#16144
• globalThis shim nim-lang/Nim#16054 (comment)

additional API's

• we also need to expose ways to get browser name + version (eg chrome 87)
• to keep codegen small, we could also support API's to avoid generating polyfills depending on a user provided set of (browsers, versions) to support, eg so that we don't generate polyfills for IE if user doesn't care about it

note

• for some things (eg BigUint64Array) writing a polyfill may be hard, but writing an auxiliary proc derived from it can be done (eg fix #16542 nim-lang/Nim#16549 (comment))
• lib/pure/hashes.nim:206:28: const uintBuffer = new BigUint64Array(buffer);

specific polyfilles

• Object.is refs fix printing negative zero in JS backend nim-lang/Nim#16505 (comment)
• BigUint64Array (missing in safari) refs fix #16542 nim-lang/Nim#16549 (comment)
  https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/BigUint64Array#Browser_compatibility
  https://bugs.webkit.org/show_bug.cgi?id=190800
• etc...

nim flag to control what to emit

—jsbrowser:chrome>=86,safari>=45
server could send polyfills depending on user agent, eg mynimproject.js split into mynimproject_no_polyfills.js and polyfills.js

examples

proc hasBigInt(): bool =
  asm """`result` = typeof BigInt == 'undefined'"""

# hasBigInt can be made generic too
proc hasJsFeature(name: static string): bool
if hasJsFeature("BigInt"): ...

[juancarlospaco]

It should be made explicit that Nim wont support IE, is Deprecated, is EOL, that can help remove old kludge code, or make it smaller.

Edge support is Ok. Edge wont need much polyfills, if any.

For browser stuff, I think that everything that can be made to work on the browser is Ok and should be made into Nim, eventually,
thats why I want the Types to be in Fusion, and then the extra sugar/proc/methods can be somewhere else if needed,
just importing the Type and sticking new proc to it.
I am slowly adding types so someday a jshttpclient and eval wasm can work with Nim+Fusion.

NodeJS, Araq dont want NodeJS specific code on the repo, thats why I created https://github.com/juancarlospaco/nodejs
and NodeJS is moving from require() to import / export, and a try catch with those 2 is not possible.

Get browser name + version should be doable with current code, maybe put that code on a proc somewhere.

cstrutils should support as much as possible of strutils, for JS.