Update to njs-0.8.0 and use js_shared_dict_zone to minimize file read

[ivanitskiy]

Proposed changes

This PR introduces NJS v0.8.0 and use js_shared_dict_zone to minimize file read. In order to update to NJS we would follow some deprecations and remove workarounds prior NJS v0.8. we have fixed some pain points we had.

Run prettier against more files and ensure npm run lint lints files.

A few notable changes from NJS v0.8.0:

• introduced js_shared_dict_zone directive
• non-compliant deprecated String methods were removed
• The following properties for CryptoKey were added:
  algorithm, extractable, type, usages
• added Array.from(), Array.prototype.toSorted(),
  Array.prototype.toSpliced(), Array.prototype.toReversed().

Checklist

Before creating a PR, run through this checklist and mark each as complete.

• I have read the CONTRIBUTING document
• If applicable, I have added tests that prove my fix is effective or that my feature works
• If applicable, I have checked that any relevant tests pass after adding my changes
• I have updated any relevant documentation (README.md and CHANGELOG.md)

[ivanitskiy]

addresses:

• Use NJS Shared Dict to store cert/key in memory #18
• remove js polyfill for Array.from  #17

[ryepup]

some questions and nits, looks like a really nice improvement.

[ryepup]

do we need the npx? eslint is in our devDependencies so I think it should be accessible as just

Suggested change

	"lint:eslint": "npx eslint .",
	"lint:eslint": "eslint .",

[ivanitskiy]

I was just following https://typescript-eslint.io/getting-started (as eslint directly did not raise a ton of issues originally, but npx eslint . did.

[ryepup]

interesting; I wonder if that's pulling in a newer version than what's in devDependencies. I don't think it's a problem, but might become one later if different tools are using different versions of eslint. JS dev tool setup is kinda an infinite source of work, so I vote we move forward with whatever works and we can iterate in the future as needed.

[ivanitskiy]

here how I tested it, by having those

    "lint": "run-p lint:*",
    "lint:eslint": "npx eslint .",
    "lint:eslint2": "eslint .",

then ran it (as you can see lint:eslint2 did not raise issues at all!! ) :

$ npm run lint

> njs-acme@1.0.0 lint
> run-p lint:*


> njs-acme@1.0.0 lint:eslint2
> eslint .


> njs-acme@1.0.0 lint:eslint
> npx eslint .


/Users/ivanitskiy/go/src/github.com/nginxinc/njs-acme-experemental/integration-tests/hooks.ts
  27:26  error  Replace `"22"` with `'22'`  prettier/prettier

✖ 1 problem (1 error, 0 warnings)
  1 error and 0 warnings potentially fixable with the `--fix` option.

ERROR: "lint:eslint2" exited with 1.

[ivanitskiy]

I personally have no idea about npx vs npm. lol

[ryepup]

I think we have enough to make the decision to cache / use zones right here, and can reduce the mutability.

Suggested change

	let cache = false
	let path = ''
	const prefix = acmeDir(r)
	const serverNames = acmeServerNames(r)
	const commonName = serverNames[0].toLowerCase()
	const zone = acmeZoneName(r)
	let path = ''
	const prefix = acmeDir(r)
	const serverNames = acmeServerNames(r)
	const commonName = serverNames[0].toLowerCase()
	const zone = acmeZoneName(r)
	const cache = zone && ngx.shared && ngx.shared[zone]

The cache will be falsy or the zone, so I think later down we can do things like:

if (cache) {
  data = (cache.get(key) as string) || ''
  if (data) {
    return data
  }
}
// ... code omitted ...
if (cache && data) {
  cache.set(key, data)
}

[ryepup]

Suggested change

	# if whant to use `js_shared_dict_zone` or have already one defined
	# use a `js_shared_dict_zone` to store certs/keys in memory