Afonso Santos

My proposal for this would be "wrapping" those 2 functions as in: instead of ` import { StoreProvider } from 'easy-peasy'` we would do ``` import { Store } from...

@ctrlplusb The only thing I dont like that much about that approach is that you are still obligated to know at the root level about the entire app state model...

@ctrlplusb exactly,something disjoint from the store, I would like to have the store created with just mandatory models for it to work and on demand based on user specific roles...

@ctrlplusb hey again, going to pick this up soon as well, anything you would like to discuss regarding the proposal?

@paulintrognon I was just going to do the same as you :D could you release it as a separate package called ```cypress-dotenv-flow```? This way we can have a dotenv only...

@wujekbogdan I agree with the object syntax for parameters as well also great Idea on making the `dotenv` package an injected dependency! :) how about ```javascript const dotenvPlugin = require('cypress-dotenv');...

script on package.json -> "build": "node -r dotenv-flow/config 'node_modules/@rescripts/cli/bin/rescripts.js' build" have fun, thats my dirty hack on projects using rescripts... you need this https://www.npmjs.com/package/dotenv-flow @jonathantneal

@goransh good catch yeah you need to set the node-env since only inside the build script those are being hardcoded, dotenv is running before so the NODE_ENV it uses is...

`options.fallbackError` is never executed with the thrown error, there isn't a code flow that reaches that statement. if `debug = false && allowExternalRules = false`, rule returns false and fallbackError...

in generator.ts, the following `else if` is never reached as well in any case ``` else if (options.allowExternalErrors) { return err ```