Closed chefhoobajoob closed 2 years ago
This is indeed a regression compared to the old vertx lang js.
I'm not sure if we should keep adding more globals, or instead add it to the existing process
global.
The process
already includes access to system properties and environment variables, we could add an extension there to get the config as a json object, e.g.:
$ cat config.json
{ "foo": "bar" }
$ cat script.js
console.log(process.config.foo)
$ es4x run --conf config.json script.js
bar
Or should we try to handle this differently?
config
global like in the past?require('config') / import * from 'config'
?seems like vertx.getOrCreateContext().config()
should be an option too - does the context detection not work as expected when invoked on the vertx
global from an es4x module?
If config is added to process
, could it be guaranteed to have different values for different modules launched from vertx.deployVerticle()
?
Yes, the way process
works in es4x, is that in fact it doesn't really represent a OS process but in fact a vert.x deployment. So if you deploy 2 verticles, the process object will be different between the 2.
See reproducer here, using es4x 0.15.0: https://github.com/chefhoobajoob/es4x-graal-js-error-reproducer
If successfully loaded, when an es4x module executes, the global
config
object is always empty, regardless of config provided tovertx.deployVerticle()
.