Theia process environment variables

We have theia running in a container and then published into openshift. We setup a .npmrc file to point to a private npm registry. When theia is running, we open a terminal and the there a number of environment variables have been created (these are present in theia), i.e. npm_config_repository - where in the theia code base do these get created?
I’m trying to debug an issue where on openshift the environment variable is being set to a different value to that in the .npmrc file (just running in Docker is ok).

Theia simply inherits env var of your shell.

If I launch theia and open a terminal window, and type the following:
env | grep ^npm_
I get 60+ environment variables that are definitely not declared in my shell.
e.g.
npm_package_theaPlugins_vscode_builtin_json
npm_package_theia_target
npm_config_registry

How do you start Theia? Maybe via yarn or npm and they are mutating env variables while forking processes?

The installation is created from the yeoman generator as we have developed an extension.
To run theia we do a “yarn theia start” from the browser-app folder. This is called from a bash script in the container.

Interesting. I was never aware of these environment variables. Running env | grep ^npm_ in a terminal on my laptop I see nothing. However if I do so in the Theia example application’s terminal, then I see a bunch of these.

I’ll dig a bit more to see where these come from.

I could not find where these env vars are defined, looking quickly. I thought maybe the they could be related to some vscode built-in extensions, but even running without any I still see the npm_* variables from the app’s terminal.

Ok, I do not have the full picture but probably a good clue: the npm_* environment variables disappear if I strip away build/test dependencies. i.e. the last command:

$ yarn install
$ yarn theia build
$ yarn install --production

This is usually how we do it in our Docker examples, but one could chose to keen them in place.

I had an idea to narrow it down further. Conclusion: The _npm* variables are present if I start the app using the Theia CLI, and not when I start it directly like so:

node src-gen/backend/main.js  
1 Like

Thanks for the replies, I did get around the issue, not really a fix though - I created the environment that was causing an issue in uppercase, and this got read in first.
Regarding running
yarn --production
I wanted to use this to reduce the size of the distribution down but I couldn’t get theia to start, I did copy what was in the Docker examples you have. Not sure if it is the project has an extension. When I run the application I get the error Cannot find module ‘yargs’.

I think it would be the best approach if you want to by pass npm/yarn and whatever side effects they cause.

Hi @StevieD666,

One trick I have used to troubleshoot in Docker: comment-out the part where your Theia app is built and use /bin/bash as your entrypoint. Then you can interactively build the app interactively and troubleshoot it.

One potential issue with yargs is that it’s pulled through many dependency paths, many different versions, and the version that “wins” by being the most “popular” for your app is hoisted. It can happen that the hoisted version is not appropriate and causes issues.

One useful command: yarn why. e.g.:

$ yarn why yargs
 yarn why yargs
yarn why v1.22.4
[1/4] Why do we have the module "yargs"...?
[2/4] Initialising dependency graph...
[3/4] Finding dependency...
[4/4] Calculating file sizes...
=> Found "yargs@11.1.1"
info Has been hoisted to "yargs"
info Reasons this module exists
   - "workspace-aggregator-3739f113-76c2-4d7c-8ce3-582c84908e2b" depends on it
   - Hoisted from "_project_#@theia#electron#yargs"
   - Hoisted from "_project_#@theia#core#yargs"
   - Hoisted from "_project_#@theia#cli#yargs"
   - Hoisted from "_project_#@theia#cli#puppeteer-to-istanbul#yargs"
   - Hoisted from "_project_#@theia#application-manager#webpack-cli#yargs"
=> Found "nyc#yargs@15.1.0"
info This module exists because "_project_#nyc" depends on it.
=> Found "electron-mocha#yargs@15.1.0"
info This module exists because "_project_#electron-mocha" depends on it.
=> Found "lerna#yargs@8.0.2"
info This module exists because "_project_#lerna" depends on it.
=> Found "mocha#yargs@13.3.0"
info This module exists because "_project_#@theia#cli#mocha" depends on it.
=> Found "showdown#yargs@14.2.2"
info This module exists because "_project_#@theia#vsx-registry#showdown" depends on it.
=> Found "electron-rebuild#yargs@14.2.3"
info This module exists because "_project_#@theia#application-manager#electron-rebuild" depends on it.
=> Found "yargs-unparser#yargs@13.3.0"
info This module exists because "_project_#@theia#cli#mocha#yargs-unparser" depends on it.
=> Found "glob-all#yargs@1.2.6"
info This module exists because "_project_#@theia#application-manager#webpack-cli#glob-all" depends on it.
Done in 3.53s.

In this case, yargs@11.1.1 ends-up being hoisted.