js -d:nodejs now supports osenv: getEnv, putEnv, envPairs, delEnv, existsEnv (v2)

[timotheecour]

alternative approach to #15475, aimed at minimizing impact on existing code to reduce complexity, so that nodejs can be supported on a best effort basis without adding undue burden on maintenance.

As you can see here https://github.com/nim-lang/Nim/pull/15826/files?diff=split&w=1 (hiding whitespace in the diff), the diff essentially amounts to adding a a single when defined(nodejs): X else: Y and re-indenting the existing Y

• getEnv + friends now work with -d:nodejs
• getEnv + friends still works in VM (with js or js+nodejs or other backend)

see relevant discussion in previous PR, in particular rationale eg #15475 (comment)

future work

• need support in vmops: envPairs, delEnv
• paramCount, paramStr, refs How to access command line parameters under the JS backend - Nim forum
  => [nodejs backend] paramStr, paramCount #17082

[nc-x]

Before merging this, please first discuss a policy regarding future maintenance and the criteria for supporting/not supporting other nodejs functions.

supported on a best effort basis

IMO supported is pretty much the opposite of best effort basis in software development

Most other languages have something like supported tiers/platforms on their website, IMO we should have it too (Apologies, if it is already present somewhere, I could not find it) -
https://ziglang.org/#Support-Table
https://doc.rust-lang.org/nightly/rustc/platform-support.html
https://haxe.org/documentation/introduction/compiler-targets.html

[timotheecour]

please first discuss a policy regarding future maintenance and the criteria for supporting/not supporting other nodejs functions.

nodejs would be a Tier 2: mostly maintained by individuals, tested in testament as part of CI, with the explicit 2-fold goals:

• avoiding software silos (eg: software not written with nodejs in mind should ideally work for nodejs, without requiring patching code)
• PR's that improve nodejs support are welcome so long they don't add undue burden on code maintenance for the officially supported backends

Most other languages have something like supported tiers/platforms on their website, IMO we should have it too

good idea

[Araq]

Tiers only help a little bit, in practice we would still get bug reports and PRs for the "Tier 2" targets. You can only argue that the benefits are worth the costs for -d:nodejs. And I doubt it.

[nc-x]

Tiers only help a little bit, in practice we would still get bug reports and PRs for the "Tier 2" targets.

Well, that's the thing. The issues and pr's will get opened whether you apply this tiering mechanism or not. So there are two options -

1. Close all issues and prs related to nodejs.
2. Mark all such issues and pr's with label 'Tier 2 - Community Supported' and/or assign Timothee to them 😄

Personally I am fine with both. I do not use nodejs, and I would prefer the core team to focus on important features and bug fixes.

Edit:
In any case, if this PR is accepted, then IMO we need to have these tiers defined. Tiers might not mean much for the core team, but for any person who might be evaluating nim for a particular use case, these tiers would mean a lot.

[juancarlospaco]

jsosenv.nim on Fusion.

[timotheecour]

jsosenv.nim on Fusion.

this would entirely defeat the purpose, it would make any code containing import os incompatible with nodejs, ie a software silo; you'd have to end up duplicating existing functionality (not just in os.nim but in modules that import os.nim) for no benefit.

The costs involved are being blown out of proportion; accomodating nodejs can be written (as in this PR) with minimal interaction. And yes, I've written quite a few PR's for os.nim.

One of the main points of os.nim is to abstract away platform/backend differences so that other libraries written on top of it work across the board without having to deal with platform specific logic to a large extent. That's the real benefit.

[timotheecour]

Thanks for merging this.