Closed JThobbyist closed 2 years ago
This is intentional. You can work around it with process.env = process.env;
, but the idea is that you don't want process.env
in memory all the time, since it's just using up space that you'll need for code in an embedded target. So, whenever you read it, it is created on demand and freed afterwards,
Do you have a specific reason you want to write it?
Yes, I wanted to merge in a bunch of parameters that control the way that the JS program operates, and have it available via http so that the server can easily view and update the config in a device- and firmware-aware manner. And, some of the JS files on boot should merge properties into it that are later accessed by other JS files. If process.env=process.env is a good workaround, then I suppose that’s easy enough to use, but maybe the Software Reference docs should just mention that it’s normally read-only for this reason, but can be made writable with the workaround? On Nov 2, 2022, at 5:06 AM, Gordon Williams @.***> wrote: This is intentional. You can work around it with process.env = process.env;, but the idea is that you don't want process.env in memory all the time, since it's just using up space that you'll need for code in an embedded target. So, whenever you read it, it is created on demand and freed afterwards, Do you have a specific reason you want to write it?
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: @.***>
maybe the Software Reference docs should just mention that it’s normally read-only for this reason, but can be made writable with the workaround?
Sure! I'll add that to the docs.
However, if you're trying to make something to control how your code works it might be better to implement it as a separate variable. process.env
contains things like the build hash and pointers to places in memory - exposing those over http (if not behind some kind of authentication) probably isn't great for security
process.env
is read-only, when it should be writable. This appears to be an issue in all Espruino implementations (tested on both Bangle2 emulator and ESP32). In NodeJS it is writable.