.env file not found when using monorepo

[nlaffey-icario]

We have an application that's using RushJS, a monorepo manager. Because of this the node_modules aren't in the typical location. When I console.log the projectFolderPath. I can see that it's resolving to: /Users/nickl/git/MyApp/common/temp/node_modules/.pnpm/@streamlinehq+streamlinehq@2.1.0/node_modules/@streamlinehq/streamlinehq/build/../../../..

The resulting error in the build is:

STREAMLINE_FAMILIES env var must be proper JSON
Error
STREAMLINE_FAMILIES and STREAMLINE_SECRET must be set in your env or .streamlinehq.json file must be present in parent folder

Ideally it would look for a .env at the root of the project /Users/nickl/git/MyApp, or where the npm script was ran from: /Users/nickl/git/MyApp/apps/MySubPackage.

I'm not sure what the right solution for this problem is. It seems like one solution would be to have the ability to set an environment variable to tell it where the root of the project is.

We might be leaning towards just the placing the static files into our own repo or S3 so we don't need to deal with setting environment variables across our CI/CD.

[cbrwizard]

Hey, could you please try the options specified here? https://github.com/webalys-hq/streamlinehq-npm#i-cannot-use-env-file-which-options-do-i-have Please let me know how it goes.

[nlaffey-icario]

Hey @cbrwizard, I agree that would work but I feel it would be easier for my team if we didn't need to set environment variables in our npm scripts and risk accidentally checking in secrets or needing people to maintain environment variables in their own bash scripts. I'd feel better if we could just gitignore the .env file and then securely pass each other the .env file for local development.

There's definitely work arounds here but it might be enough for us to just go a different route all together.

[cbrwizard]

Hey, please check if this release solves your problem https://github.com/webalys-hq/streamlinehq-npm/releases/tag/3.0.4

[galarbel]

if it helps anyone - when working with PNPM (didn't test with their workspace solution yet)

it really isn't that a great of a solution - but I've used a hack modifying pnpm install.

1. change your streamlinehq.json in your root to:

   {
   "STREAMLINE_FAMILIES": "[\"SOME-FAMILY\"]",
   "STREAMLINE_SECRET": "YOUR-KEY"
   }

2. add a .pnpmfile.cjs in your root dir with:

   
   const { env } = require("process");
   const streamlineJson = require("./x_streamlinehq.json"); // I've used x_streamlinehq.json instead

function readPackage(pkg, context) { Object.entries(streamlineJson).forEach(([key, value]) => { env[key] = value });

return pkg; }

module.exports = { hooks: { readPackage } }

it seems like when running _pnpm install_ - it's ignoring the .env file, and it's looking for the .streamlinehq.json in
_node_modules/.pnpm/registry.npmjs.org+@streamlinehq+streamlinehq@3.0.4/streamlinehq.json_

I'm guessing this trick can also be used with using the pnpmfile.cjs to set STREAMLINE_RELATIVE_PROJECT_FOLDER_PATH instead, but it didn't seem consistent between dev-environments (we have some with mac, windows and linux) and the relative project folder path was different for which (not really sure why, it just didn't seem to work well)
setting up the ENV variable for the terminal seems annoying. each new dev and each new env we need to remember to set it up... seems like a hassle. I'd rather have a solution that fits all ENVs without doing any extra steps

[mijamo]

@cbrwizard The problem seems to still be there in 3.0.4, although I am not 100% sure if this is because of this issue or because of https://github.com/webalys-hq/streamlinehq-npm/issues/22

[cbrwizard]

Today we announce that we're deprecating the Streamline NPM package. Instead, we’ll focus on the web app and Figma plugin, which are used by a noticeable share of our customers.

Please from now on instead of using our brittle package download the images directly from our website and insert them into your project as SVG files. Meanwhile, Streamline team is focused on ensuring that our web application provides the best user experience for developers' use cases. Please take 2 minutes to share feedback so that we can improve.

We'll keep this package with minimal life support until 1st November 2022, after which it's going to be deleted.

Please read the full story in this article.