Closed DanielRuf closed 4 years ago
@DanielRuf I'm a bit confused,
Do you use node-windows
in an application that creates its one/multiple services, or are using node-windows
to create a single service based on the application?
If the second is true, then, if I'm not mistaken, you have to set environment variables in the initialization process of the service, if you use dotenv
in the application itself, you wont get the correct variables, if any, because the application doesnt run in the same working directory as the application itself.
-- you MIGHT be able to put a .env
file in daemon folder once the service is created, but I'm not 100% sure.
-- I'll test when I get home whether not that works.
In general it is the issue with the missing cwd
and that the service runs somewhere else and so any reltive path will not work (and so many packages will break).
Writing env files into the script for starting the server is also no option as this reveals secrets which should be only in a gitignored or hidden .env file.
We will probably switch to pm2 to handle this as it should work with this and let node-windows
only start the pm2 process.
I don't use dotenv, and perhaps this is not helpful, but localenvironment may be an alternative. I've used it with node-windows in the past.
Does this work with scripts which are run as service by default? Because dotenv did not read the file because of where the service runs (it seems so).
The custom file feature allows you to specify the location of your environment file. If no path is provided, then it looks in the current working directory, which I suspect is the same functionality as dotenv. The real difference is localenvironment gives developers an option to specify the path. Depending on the use case, I typically use this with __dirname
or process.cwd()
to help identify the appropriate location of the config file.
You could use dotenv
in the initialization process, and pass the variables directly into the service at that point. -- this is how I personally use it.
But this localenvironment
seems like the way to go
const { Service } = require('node-windows');
require('dotenv').config()
const serviceName = "Test",
serviceDescription = "Description"
const service = new Service({
name: serviceName,
description: serviceDescription,
script: path.join(process.cwd(), "./app.js"),
env: process.env,
})
This does, however, create an xml
file that contains the environment variables in a daemon folder right next to script file
@demitchell14 thanks for pointing to this solution and approach. I think this can be better documented as example in the docs. At least I do not seem to be the only one struggling with this.
But in general we might move this part to pm2 which has better log handling by default (no need to change / adapt parts to the custom EventLogger) and management of running applications.
Adding another dependency like localenvironment is not what I plan to do (reuse the current dependencies as far as possible) but thanks for mentioning this =)
In our case we use
node-windows
to run a backend service as Windows service which uses the following command under the hood:In the service we load a
.env
file usingdotenv
.But
require('dotenv').config()
seems to not correctly load the file as the values areundefined
.