bug: Invalid or unexpected token at Module._compile about jose HOT 11 CLOSED

No, its correct. node >=12.0.0 is the described minimal version for its keyobject and crypto api additions and with node 12 come private class fields which i’m glad to have available as a side effect.

from jose.

However, you just have to accept that as a result your library might not be used.

And I'm okay with that, fully expected that. If one cannot / doesn't want to use node 12 yet, there are long time available and popular alternatives, I'm not hiding the fact this is >=12.0.0, just like i'm fully declaring one cannot use this transpiled in a browser since the API just isn't there in webcrypto either.

I could split myself in two and there would still be no way to get these new APIs in older versions of node since they require minimal version of OpenSSL that is higher than what older node versions can be built with, hence the crypto maintainers chose to go the way of making this semver-major in node with no way to backport.

from jose.

It is the current stable release line and a future LTS. Its features (not just the available syntax) are mentioned to be the prerequisite in the readme.

from jose.

No there is not. APIs were added in 11.6.0 and 12.0.0.

https://github.com/lambci/node-custom-lambda you can run node 12 in lambda

from jose.

#37 https://v8.dev/features/class-fields

from jose.

That version is not current stable version. @panva

from jose.

@panva currently lambda's support stops at node 10.
https://docs.aws.amazon.com/lambda/latest/dg/programming-model.html

Is there a way to use your library in node v10?

from jose.

For those wondering, Node v12 won't be LTS until Nov 22, 2019 (see schedule).

Also, the Node website states "Production applications should only use Active LTS or Maintenance LTS releases." It would be good to call that out so people aren't upgrading their productions environments thinking they are outdated.

from jose.

@tysonmatanich while that may be true there’s nothing against targetting the current release line for new features, such as is the case of this library.

The CI that runs daily also runs with the most recent current version on multiple platforms (e.g. mac, windows, linux) as well as the nightly release. With the current release line there are no breaking changes to stable apis and the same cadence of security fixes.

The crypto API also recommends the use KeyObjects over the old way of passing PEM formatted keys for all available operations for both security and performance reasons.

from jose.

@panva i'm totally on board with your reasoning. however, you just have to accept that as a result your library might not be used. I found it to be simpler and less thought provoking to use a combination of node-jose and jsonwebtoken instead of upgrading my lambda layers. also notice there is a cold boot penalty for doing so (at least for now). so my solution is in package.json "@types/jsonwebtoken": "^8.3.2", "@types/node-jose": "^1.1.0", "jsonwebtoken": "^8.5.1", "node-jose": "^1.1.3", and a little bit of code on top.

from jose.

I've made @panva/jose compatible with lts/dubnium, it is now being tested with Node.js ^10.13.0 || >=12.0.0 and Electron ^6.0.0

It is not without caveats, but they are acceptable.

• Importing X.509 certificates and handling x5c is only supported when Node.js >= 12.0.0 runtime is detected
• OKP keys are only supported when Node.js >= 12.0.0 runtime is detected

from jose.