Nat  Grady

Nat Grady

1658346780

Shell-env: Get Environment Variables From The Shell

shell-env

Get environment variables from the shell

Especially useful for Electron apps as GUI apps on macOS doesn't inherit the environment variables defined in your dotfiles (.bash_profile/.zshrc/etc).

Install

$ npm install shell-env

Usage

import {shellEnv} from 'shell-env';

console.log(await shellEnv());
//=> {TERM_PROGRAM: 'Apple_Terminal', SHELL: '/bin/zsh', ...}

console.log(await shellEnv('/bin/bash'));
//=> {TERM_PROGRAM: 'iTerm.app', SHELL: '/bin/zsh', ...}

API

Note that for Bash, it reads .bash_profile, but not .bashrc.

shellEnv(shell?)

Return a promise for the environment variables.

shellEnvSync(shell?)

Returns the environment variables.

shell

Type: string
Default: User default shell

Shell to read the environment variables from.

Related

  • shell-path - Get the $PATH from the shell
  • fix-path - Fix the $PATH on macOS when run from a GUI app
  • shell-history - Get the command history of the user's shell

Author: Sindresorhus
Source Code: https://github.com/sindresorhus/shell-env 
License: MIT license

#electron #shell #env 

Shell-env: Get Environment Variables From The Shell
Mike  Kozey

Mike Kozey

1657732260

ENV_manager: Manage Your Application's Environment with Env_manager

Usually in an application it is necessary to have at hand a system to manage global variables (or environment variables) to propagate inside the application. env_manager does just that, it manages your environment variables in a smart way.

How it works

Your environment variables are stored in a folder called envdir, this folder will contain all of your environment variable files and you can divide them up as you see fit.

Below is an example of a project folder that uses env_manager.

your_project
├───android
│└───...
├───assets
│└───...
├───build
│└───...
│
├───envdir
│├───application.yaml
│├───another_env_file.yaml
│└───example_env_folder
│    └───example_env_file_inside_folder.yaml
│
├───ios
│└───...
├───lib
│└───...
├───test
│└───...
├───.flutter-plugins
├───.flutter-plugins-dependencies
├───.gitattributes
├───.gitignore
├───.metadata
├───.packages
├───analysis_options.yml
├───your_project.iml
├───pubspec.lock
├───pubspec.yaml
└───README.md

Setup the package in your application

Add the package in the dependecies section of your pubspec.yaml file.

env_manager: ^0.1.2

and execute the flutter pub get to fetch the package from pub.dev.

After the fetch, execute the flutter pub run env_manager:make to create the envdir in your project root directory, inside this folder your can create all your environment files (even with different folders).

IMPORTANT: All environment files must use the following format

production:
    example_A_variable: "My A variable in production"
    example_B_variable: "My B variable in prodution"
    ...

development:
    example_A_variable: "My A variable in development"
    example_B_variable: "My B variable in development"

All variables must be the same for production and development sections.

After this, you need to add the environment files in the assets section inside the pubspec.yaml file.

...
flutter:
    assets:
        - assets/myexampleimage.png
        - assets/anotherexampleimage.jpg
        ...

        #Env Files
        - envdir/application.yaml
        - envdir/example_folder/new_env_file.yaml
        ...
...

Add the code in your application

In your main class, add the following snippt before the runApp method

...
void main() async {
    WidgetsFlutterBinding.ensureInitialized();

    await env.locateAndLoad([
        env.EnvironmentFileLoader("myEnvName", await rootBundle.loadString("envdir/application.yaml")),
        env.EnvironmentFileLoader("myEnvName2", await rootBundle.loadString("envdir/example_folder/new_env_file.yaml")),
        ..other files to load..
    ]);

    ...
}
...

You can also setup the environment to reply with production variables or with development variables using

env.useProductionEnvironment(true | false);

IMPORTANT: By default is set to false

or you can call directly the environment using the get method (By default will take the useProductionEnvironment value)

env.get("myEnvName")["variable_name"]
env.get("myEnvName", withProduction: true | false)["variable_name"]

Installing

Use this package as a library

Depend on it

Run this command:

With Flutter:

 $ flutter pub add env_manager

This will add a line like this to your package's pubspec.yaml (and run an implicit flutter pub get):

dependencies:
  env_manager: ^0.1.2

Alternatively, your editor might support flutter pub get. Check the docs for your editor to learn more.

Import it

Now in your Dart code, you can use:

import 'package:env_manager/env_manager.dart';

example/main.dart

import 'package:flutter/material.dart';
import 'package:env_manager/env_manager.dart' as env;
import 'package:flutter/services.dart';

void main() async {
  WidgetsFlutterBinding.ensureInitialized();

  await env.locateAndLoad([
    env.EnvironmentFileLoader(
        "myEnvName", await rootBundle.loadString("envdir/application.yaml")),
  ]);

  //Optional
  env.useProductionEnvironment(true);

  runApp(MaterialApp(
    title: env.get("myEnvName")["application_name"],
    home: const MyApplication(),
  ));
}

class MyApplication extends StatefulWidget {
  const MyApplication({Key? key}) : super(key: key);

  @override
  _MyApplicationState createState() => _MyApplicationState();
}

class _MyApplicationState extends State<MyApplication> {
  @override
  void initState() {
    super.initState();

    env.useProductionEnvironment(true);
  }

  @override
  Widget build(BuildContext context) {
    return Scaffold(
      body: Container(
        alignment: Alignment.center,
        child: Text(env.get("myEnvName")["my_env_variable"]),
      ),
    );
  }
}

Author: Giannuzzoexe
Source Code: https://github.com/giannuzzoexe/env_manager 
License: BSD-3-Clause license

#flutter #dart #managed #env 

ENV_manager: Manage Your Application's Environment with Env_manager
Hermann  Frami

Hermann Frami

1656912240

Serverless Sthree Env

STHREE ENV PLUGIN

This plugin is used to get config from a json formatted file in S3 and copy them to environment variable

HOW TO USE

  • just include 'serverless-sthree-env' plugin to your serverless yml file

For now it is quite simple, the bucket and config key name is predefined based on

Bucket: (service name)-config-(stage) Key: config.json

everything in that key will be copied over to your environment variable

eg. service name is my-apps and I am using dev stage

so create a bucket in the same region with the name my-apps-config-dev and config.json file inside there like below

{
  "KEY": "VALUE" 
}

FUTURE IMPROVEMENT

  • Create serverless command to create a config bucket
  • Allow selection of config bucket and key
  • Whitelist or blacklist env variable to be copied

Author: StyleTributeIT 
Source Code: https://github.com/StyleTributeIT/serverless-sthree-env 
License: 

#serverless #env #s3 

Serverless Sthree Env
Hermann  Frami

Hermann Frami

1656547380

Serverless Resources Env

Serverless-resources-env

A serverless framework plugin so that your functions know how to use resources created by cloudformation.

In short, whether you are running your function as a lambda, or locally on your machine, the physical name or ARN of each resource that was part of your CloudFormation template will be available as an environment variable keyed to its logical name prefixed with CF_.

For lambdas running on AWS, this plugin will set environment variables on your functions within lambda using the Lambda environment variable support.

For running functions locally, it will also create a local env file for use in reading in environment variables for a specific region-stage-function while running functions locally. These are by default stored in a directory named: .serverless-resources-env in files named .<region>_<stage>_<function-name>. Ex: ./.serverless-resources-env/.us-east-1_dev_hello. These environment variables are set automatically by the plugin when running serverless invoke local -f ....

Breaking Changes in 0.3.0: See below

Why?

You have a CloudFormation template all set, and you are writing your functions. Now you are ready to use the resources created as part of your CF template. Well, you need to know about them! You could deploy and then try and manage configuration for these resources, or you can use this module which will automatically set environmet variables that map the logical resource name to the physical resource name for resources within the CloudFormation file.

Example:

You have defined resources in your serverless.yml called mySQS and myTable, and you want to actually use these in your function so you need their ARN or the actual table name that was created.

const sqs_arn = process.env.CF_mySQS;
const my_dynamo_table_name = process.env.CF_myTable;

How it works

This plugin attaches to the deploy post-deploy hook. After the stack is deployed to AWS, the plugin determines the name of the cloud formation stack, and queries AWS for all resources in this stack.

After deployment, this plugin, will fetch all the CF resources for the current stack (stage i.e. 'dev'). It will then use the AWS SDK to set as environment variables the physical id's of each resource as an environment variable prefixed with CF_.

It will also create a file with these values in a .properties file format named ./serverless-resources-env/.<region>_<stage>_<function-name>. These are then pulled in during a local invocation (serverless invoke local -f...) Each region, stage, and function will get its own file. When invoking locally the module will automatically select the correct .env information based on which region and stage is set.

This means no code changes, or config changes no matter how many regions, and stages you deploy to.

The lambdas always know exactly where to find their resources, whether that resource is a DynamoDB, SQS, SNS, or anything else.

Install / Setup

npm install serverless-resources-env --save

Add the plugin to the serverless.yml.

plugins:
  - serverless-resources-env

Set your resources as normal:

resources:
  Resources:
    testTopic1:
      Type: AWS::SNS::Topic
    testTopic2:
      Type: AWS::SNS::Topic

Set which resources you want exported on each function.

functions:
  hello:
    handler: handler.hello
    custom:
      env-resources:
        - testTopic1
        - testTopic2

Breaking Changes since 0.2.0

At version 0.2.0 and before, all resources were exported to both the local .env file and to each function automatically.

This caused issues with AWS limits on the amount of information that could be exported as env variables onto lambdas deployed within AWS. This also exposed resources as env variables that were not needed by functions, as it was setting all resources, not just the ones the function needed.

Starting at version 0.3.0 a list of which resources are to be exported to each function are required to be a part of the function definition in the .yml file, if the function needs any of these environment variables. (See current install instructions above)

This also means that specific env files are needed per region / stage / function. This can potentially be a lot of files and therefore these files were also moved to a sub-folder. .serverless-resources-env by default.

Common Errors

Unexpected key 'Environment' found in params. Your aws-sdk is out of date. Setting environment variables on lambdas is new. See the Important note above.

You may need to upgrade the version of the package aws-sdk being used by the serverless framework.

In the 1.1.0 serverless framework, the aws-sdk is pegged at version 2.6.8 in the npm-shrinkwrap.json of serverless.

If you have installed serverless locally as part of your project you can just upgrade the sdk. npm upgrade aws-sdk.

If you have installed serverless globally, you will need to change to the serverless directory and run npm upgrade aws-sdk from there.

The following commands should get it done:

cd `npm list serverless -g | head -n 1`/node_modules/serverless
npm upgrade aws-sdk

Config

By default, the mapping is written to a .env file located at ./.serverless-resources-env/.<region>_<stage-name>_env. This can be overridden by setting an option in serverless.yml.

custom:
  resource-output-dir: .alt-resource-dir
functions:
  hello:
    custom:
      resource-output-file: .alt-file-name

Author: Rurri
Source Code: https://github.com/rurri/serverless-resources-env 
License: MIT license

#serverless #aws #env #plugin 

Serverless Resources Env
Hermann  Frami

Hermann Frami

1656110400

Serverless Output to Env

serverless-output-to-env

A Serverless plugin that writes stack outputs to a .env file during after:deploy hook.

How to use?

Add the plugin to your serverless.yml

plugins:
  -serverless-output-to-env

Add plugin configuration to serverless.yml

custom:
  outputToEnv:
    fileName: ../../.env
    map:
      YOUR_ENV_KEY: YourOutput
resources:
  Outputs:
    YourOutput:
      Value:
        !Ref FooBar

How to run

It will run automatically in after:deploy hook or you can run it manually with:

serverless output-to-env

Parameters

NameRequiredData TypeDefaultDescription
fileNameYString Path to output file
mapYObject Key/Value map for .env file key to your output key.

Author: Williamsandonz
Source Code: https://github.com/williamsandonz/serverless-output-to-env 
License: MIT license

#serverless #cloud #env 

Serverless Output to Env

Nixt: Simple and Elegant End-to-end Testing for Command-line Apps

Synopsis

Simple and powerful end-to-end testing for command-line apps.

Description

Nixt is aiming to make testing of command-line apps as simple as possible. It plays nice with the testing tools that you are already using and in case you are one of those devs who practice outside-in BDD, it has the potential to become something that lives in every command-line app that you are going to build.

How it looks

var nixt = require('nixt');

nixt()
.exec('touch /tmp/test')
.run('ls /tmp/')
.stdout(/test/)
.end();

Formatting options

Nixt can strip newlines and colors. You can tell it to do so by passing an object that looks like this:

var options = {
  colors: false,
  newlines: false,
};

nixt(options).stdout...

Custom expectations

While Nixt comes with built-in expectations, you can use your own too.

nixt()
.expect(function(result) {
  if (result.stdout !== 'unicorns') {
    return new Error('NO!');
  }
})
.run('unicorns')
.end(fn);

Custom middlewares

You can register as many before and after middlewares as you wish.

nixt()
.before(setupDatabase)
.before(runMigrations)
.run(cmd)
.after(downgradeCron)
.after(deleteDatabase)
.end();

Middleware order

The Middleware execution order is very simple - "before" middlewares always run before everything else, "after" middlewares always run after everything else. The other middlewares will match the order that you have specified.

nixt()
.before(before1)
.before(before2)
.after(after1)
.after(after2)
.writeFile(file, '')
.run(cmd)
.unlink(file)
.end(fn)

// Execution order:
// before1, before2, writeFile, cmd, unlink, after1, after2

You may also want to reuse before and after middlewares as much as possible, especially when testing something that requires extensive setup and cleanup. You can accomplish this by cloning a Nixt instance.

var base = nixt()
  .before(setupDatabase)
  .after(removeDatabase);

// Later on

base.clone().run....

Plugins

Nixt has primitive support for plugins. You can register any expectation or/and any middleware by calling nixt.register.

var fn = function() {};
nixt.register('foo', fn);

Or you may want to register many functions at once.

var fn = function() {};
var fn1 = function() {};
nixt.register({ baz: fn, bar: fn1 });

Usage with a test runner

Nixt plays nice with any test runner out there. Here is a minimal example how you could use it with Mocha.

describe('todo add', function() {
  it('adds a new todo item', function(done) {
    nixt()
    .run('todo add')
    .stdout('A new todo has been added')
    .end(done);
  });
});

Usage without a test runner

While using a test runner is recommended nixt is completely 'nodeable'. Here is a simple example how you could accomplish that:

var assert = require('assert');

function refute(err) {
  assert(!err);
}

nixt()
.run(cmd)
.end(refute);

nixt()
.run(anotherCmd)
.end(refute);

Responding to interactive prompts

Nixt can respond to apps that run interactively using the on() and respond() functions.

nixt()
.run(cmd)
.on('Your name: ').respond('Joe User\n')
.end();

See test/prompt.test.js for more examples.

API

#before

Register a "before" middleware.

nixt()
.before(fn)
.before(fn2)
.run(cmd)
.end();

#after

Register an "after" middleware.

nixt()
.run(cmd)
.after(fn)
.after(fn2)
.end();

#cwd

Change the current working directory of the main command (specified with run). Please note that this won't affect any other commands like unlink etc.

nixt()
.cwd(__dirname)
.run('pwd')
.stdout(/test$/)
.end();

#base

Set a base command. Useful for templates.

nixt()
.base('node ')
.run('--version')
.stdout('0.10.16')
.end();

#run

Set a primary command to execute:

nixt()
.run('node --version')
.stdout('0.10.16')
.end(fn);

You could also run the test right after specifying the command to run:

nixt()
.stdout('0.10.16')
.run('node --version', fn)

#stdin

Set the contents of stdin.

nixt()
.stdin('foobar')
.run('rev')
.stdout('raboof')
.end(fn);

#env

Set environment variables.

nixt()
.env('foo', 'bar')
.env('baz', 'boo')
.run('node --version')
.stdout('0.10.16')
.end(fn);

#timeout

Set a timeout for the main command that you are about to test.

nixt()
.timeout(1) // ms
.run('cat /dev/null')
.end(fn);

#stdout

Set expectations on stdout.

nixt()
.stdout('LICENSE Makefile')
.run('ls')
.end(fn);

Works with regular expressions too.

nixt()
.stdout(/system/)
.run('time')
.end(fn);

#stderr

Same as stdout but well.. surprise works with stderr.

nixt()
.run('todo add')
.stderr('Please speicfy a todo')
.end(fn);

#code

Expect a given exit code.

nixt()
.run('todo add')
.code(1)
.end(fn);

#exist

Check if a given path exists (works with both files and directories).

nixt()
.run('mkdir /tmp/test')
.exist('/tmp/test')
.end(fn);

#notExist

Check if a given path does not exist (works with both files and directories).

nixt()
.run('rm /tmp/file')
.notExist('/tmp/file')
.end(fn);

#match

Check the contents of a file.

nixt()
.writeFile(file, 'Hello')
.run('node void.js')
.match(file, 'Hello')
.unlink(file)
.end(done);
nixt()
.writeFile(file, 'Hello')
.run('node void.js')
.match(file, /ello/)
.unlink(file)
.end(done);

#mkdir

Create a new directory.

nixt()
.mkdir('xml-database')
.run('this does stuff with the xml-database directory')
.end(fn);

#exec

Execute a given command.

nixt()
.writeFile('LICENSE', 'MIT License')
.exec('git add -a')
.exec('git commit -m "Add LICENSE"')
.run('git log')
.stdout(/LICENSE/)
.end();

By default the commands will inherit the "world" for the main command which includes environment variables, cwd, timeout. However, you can override this by supplying a different "world":

nixt()
.exec('git add LICENSE', { timeout: 4, cwd: '/tmp' })
.run('git log')
.stdout(/LICENSE/)
.end();

#writeFile

Create a file with or without given contents.

Without:

nixt()
.writeFile(pathToFile)
.end();

With:

nixt()
.writeFile(pathToFile, data)
.end();

#rmdir

Remove a directory.

nixt()
.mkdir('xml-database')
.run('this does stuff with the xml-database directory')
.rmdir('xml-database')
.end(fn);

#unlink

Unlink a file.

nixt()
.writeFile('my-file', data)
.run('this does stuff with my file')
.unlink('my-file')
.end(fn);

#on

Detect a prompt for user input. Accepts a String or RegExp that appears in the the stdout stream. Must be paired with #respond.

nixt()
.run(cmd)
.on('Your name: ').respond('Joe User\n')
.end();

#respond

Write a response to the stdin stream when a prompt is detected.

See #on

#end

Run the given test.

nixt()
.run('ls')
.stdout('this-is-not-porn-i-promise')
.end(function(err) {

});

The same might be accomplished with supplying a function to run:

nixt()
.stdout('this-is-not-porn-i-promise')
.run('ls', function(err) {

})

#clone

Deep clone a Nixt instance.

var clone = nixt()
.before(fn)
.after(fn)
.run('my awesome command')
.end()
.clone();

#expect

Register a custom expectation.

nixt()
.expect(function(result) {
  if (result.stdout !== 'Unicorns') {
    return new Error('OMG');
  }
})
.run('ls')
.end(fn);

Installation

$ npm install nixt

Tests

Running the tests

$ make

Credits

Special thanks to:

Support the author

Do you like this project? Star the repository, spread the word - it really helps. You may want to follow me on Twitter and GitHub. Thanks!

Author: Vesln
Source Code: https://github.com/vesln/nixt 
License: MIT license

#javascript #testing 

Nixt: Simple and Elegant End-to-end Testing for Command-line Apps
Hermann  Frami

Hermann Frami

1654025880

Serverless Export Env Plugin

⚡️ Serverless Export Env Plugin 

About

The Serverless Framework offers a very powerful feature: You can reference AWS resources anywhere from within your serverless.yml and it will automatically resolve them to their respective values during deployment. However, this only works properly once your code is deployed to AWS. The Serverless Export Env Plugin extends the Serverless Framework's built-in variable solution capabilities by adding support many additional CloudFormation intrinsic functions (Fn::GetAtt, Fn::Join, Fn::Sub, etc.) as well as variable references (AWS::Region, AWS::StackId, etc.).

The Serverless Export Env Plugin helps solve two main use cases:

  1. It will automatically hook into the sls invoke local and sls offline start (see Serverless Offline Plugin) and help resolve your environment variables. This is fully transparent to your application and other plugins.
  2. Invoke sls export-env from the command line to generate a .env file on your local filesystem. Then use a library such as dotenv to import it into your code, e.g. during local integration tests.

Usage

Add the npm package to your project:

# Via yarn
$ yarn add arabold/serverless-export-env --dev

# Via npm
$ npm install arabold/serverless-export-env --save-dev

Add the plugin to your serverless.yml. It should be listed first to ensure it can resolve your environment variables before other plugins see them:

plugins:
  - serverless-export-env

That's it! You can now call sls export-env in your terminal to generate the .env file. Or, you can run sls invoke local -f FUNCTION or sls offline start to run your code locally as usual.

Examples

sls export-env

This will export all project-wide environment variables into a .env file in your project root folder.

sls export-env --function MyFunction --filename .env-MyFunction

This will export environment variables of the MyFunction Lambda function into a .env-MyFunction file in your project root folder.

Referencing CloudFormation resources

As mentioned before, the Serverless Framework allows you to reference AWS resources anywhere from within your serverless.yml and it will automatically resolve them to their respective values during deployment. However, Serverless' built-in variable resolution is limited and will not always work when run locally. The Serverless Export Env Plugin extends this functionality and automatically resolves commonly used intrinsic functions and initializes your local environment properly.

Supported instrinsic functions

  • Condition Functions
    • Fn::And
    • Fn::Equals
    • Fn::If
    • Fn::Not
    • Fn::Or
  • Fn::FindInMap
  • Fn::GetAtt
  • Fn::GetAZs
  • Fn::Join
  • Fn::Select
  • Fn::Split
  • Fn::Sub (at the moment only key-value map subtitution is supported)
  • Fn::ImportValue
  • Ref

Examples

provider:
  environment:
    S3_BUCKET_URL:
      Fn::Join:
        - ""
        - - https://s3.amazonaws.com/
          - Ref: MyBucket

Or the short version:

provider:
  environment:
    S3_BUCKET_URL: !Join ["", [https://s3.amazonaws.com/, Ref: MyBucket]]

You can then access the environment variable in your code the usual way (e.g. process.env.S3_BUCKET_URL).

Configuration

The plugin supports various configuration options under custom.export-env in your serverless.yml file:

custom:
  export-env:
    filename: .env
    overwrite: false
    enableOffline: true

Configuration Options

OptionDefaultDescription
filename.envTarget file name where to write the environment variables to, relative to the project root.
enableOfflinetrueEvaluate the environment variables when running sls invoke local or sls offline start.
overwritefalseOverwrite the file even if it exists already.
refMap{}Mapping of resource resolutions for the Ref function
getAttMap{}Mapping of resource resolutions for the Fn::GetAtt function
importValueMap{}Mapping of resource resolutions for the Fn::ImportValue function

Custom Resource Resolution

The plugin will try its best to resolve resource references like Ref, Fn::GetAtt, and Fn::ImportValue for you. However, sometimes this might fail, or you might want to use mocked values instead. In those cases, you can override those values using the refMap, getAttMap, and importValueMap options.

  • refMap takes a mapping of resource name to value pairs.
  • getAttMap takes a mapping of resource name to attribute/value pairs.
  • importValueMap takes a mapping of import name to value pairs.
custom:
  export-env:
    refMap:
      # Resolve `!Ref MyDynamoDbTable` as `mock-myTable`
      MyDynamoDbTable: "mock-myTable"
    getAttMap:
      # Resolve `!GetAtt MyElasticSearchInstance.DomainEndpoint` as `localhost:9200`
      MyElasticSearchInstance:
        DomainEndpoint: "localhost:9200"
    importValueMap:
      # Resolve `!ImportValue MyLambdaFunction` as `arn:aws:lambda:us-east-2::function:my-lambda-function`
      MyLambdaFunction: "arn:aws:lambda:us-east-2::function:my-lambda-function"

👉 Generally, it is recommended to avoid the use of intrinsic functions in your environment variables. Often, the same can be achieved by simply predefining a resource name and then manually construct the desired variable values. To share resources between different Serverless services, check out the ${cf:stackName.outputKey} variable resolution mechanism.

Command-Line Options

Running sls export-env will, by default, only export global environment variables into your .env file (those defined under provider.environment in your serverless.yml). If you want to generate the .env file for a specific function, pass the function name as a command-line argument as follows:

sls export-env --function hello --filename .env-hello
OptionDescription
filenameTarget filename where to write the environment variables to, relative to the project root.
overwriteOverwrite the file even if it exists already.
functionName of a function for which to generate the .env file.
allMerge environment variables of all functions into a single .env file.

Provided lifecycle events

  • export-env:collect - Collect environment variables from Serverless
  • export-env:resolve - Resolve CloudFormation references and import variables
  • export-env:apply - Set environment variables when testing Lambda functions locally
  • export-env:write - Write environment variables to file

Migrating from 1.x to 2.x

  • Running sls invoke local or sls offline start will no longer create or update your .env file. If you want to create an .env file, simply run sls export-env instead.
  • By default, the plugin will no longer overwrite any existing .env file. To enable overwriting existing files, either specify --overwrite in the command-line or set the custom.export-env.overwrite configuration option.
  • Resource Outputs values (resources.Resources.Outputs.*) are no longer getting exported automatically. This has always been a workaround and causes more problems than it solved. The plugin will try its best to resolve Fn::GetAtt and other references for you now, so there should be little need for the old behavior anymore. Add the desired value as an environment variable to provider.environment instead.
  • Running sls export-env will no longer merge the environment variables of all functions into a single .env file. Instead, pass the name of the desired function as --function argument to the command line. If no function name is specified, only project-wide environment variables will get exported. To bring back the old behavior, pass --all in command line and it will generate a file including all environment variables of all functions. However, please be aware that the behavior is undefined if functions use conflicting values for the same environment variable name.
  • The configuration options filename and pathFromRoot have been merged to filename now. You can specify relative paths in filename such as ./dist/.env now. Make sure the target folder exists!

Releases

2.1.0

  • Compatibility with Serverless v3.x
  • Updated dependencies minor versions

2.0.0

  • Removed optimistic variable resolution for Fn::GetAtt as it was not working properly and caused hard to solve issues. If you rely on Fn::GetAtt in your environment variables, define a custom resolution using the getAttMap configuration option.

alpha.1

  • Added --all command line parameter to merge the environment variables of all functions into a single .env file. Please note that the behavior is undefined if functions use conflicting values for the same environment variable name.

alpha.0

  • Complete rewrite of the variable resolver. We use the amazing cfn-resolver-lib lib now. This allows us to support not only Ref and Fn::ImportValue as in previous releases, but we're able to resolve the most commonly used intrinsic functions automatically now.

1.x Releases

1.4.4

  • Reverted changes in 1.4.1. Unfortunately, we broke the semver contract by introducing a breaking feature in a patch update. This feature needs to be rethought and added back in a 1.5.x release as optional. Until then, I had to remove it again.

1.4.3

  • Internal version (not published)

1.4.2

  • Fixed some compatibility issues with the latest Serverless framework release. Thanks to pgrzesik for the necessary updates.

1.4.1

  • Disabled calls to the real aws infrastructure when running with Serverless Offline. Thanks to marooned071 for the contribution.

1.4.0

  • Collect and set resource values from actual Cloud Formation stack output. Thanks to andersquist for his contribution!
  • Fix error when serverless.yml doesn't contain a custom section. Thanks to michael-wolfenden!

1.3.1

  • Explicitly set environment variables during local invocation of the Lambda (sls invoke local)

1.3.0

  • Support different output filename and path. Thanks to philiiiiiipp.
  • Export Outputs as environment variables. Thanks to lielran.
  • Updated to latest dependencies

1.2.0

  • Use operating-system-specific end-of-line when creating .env file

1.1.3

  • Fixed an issue with AWS::AccountId being resolved as [Object Promise] instead of the actual value.

1.1.2

  • Fixed an issue with CloudFormation resources not being resolved properly if the stack has more than 100 resources or exports.

1.1.1

  • Fix issue with multiple environment variables for function (thanks to @Nevon).

1.1.0

  • Support Fn::Join operation (contribution by @jonasho)
  • Support pseudo parameters AWS::Region, AWS::AccountId, AWS::StackId and AWS::StackName.

1.0.2

  • The plugin now properly resolves and sets the environment variables if a Lambda function is invoked locally (sls invoke local -f FUNCTION). This allows seamless as if the function would be deployed on AWS.

1.0.1

  • Corrected plugin naming
  • Improved documentation

1.0.0

  • This is the initial release with all basic functionality

Author: Arabold
Source Code: https://github.com/arabold/serverless-export-env 
License: MIT license

#serverless #aws #export #env 

Serverless Export Env Plugin

What is ENV Finance (ENV) | What is ENV Finance token | What is ENV token

In this article, we’ll discuss information about the ENV Finance project and ENV token

ENV Finance, a platform for fundraising environmental projects with cryptocurrencies and get rewarded for it.

Introduction

Classic crowdfunding does not work anymore, or better still, it’s working as usual but the concrete results are limited. It goes without saying that fundraising is a difficult task for every organization, because they ask people to trust them completely. Frequently contributors don’t even have the possibility to know how their money is actually spent and cannot follow the evolution of the projects they have funded. ENV Finance’s main goal is to give contributors total transparency of the money flow, from the initial donation to the final project reports; in addition, ENV Finance wishes to attract contributors by rewarding them for their donations, through a simple reward allocation program based on a ENV token, the new token introduced to Binance Smart Chain. Many big organizations like Greenpeace or WWF already accept donations in cryptocurrencies.

Pros

  • Transparency: all transactions are publicly registered in the Binance Smart Chain in real-time;
  • Traceability: every transaction, and every token transfer, can be tracked from its beginning, because all transactions and relative wallets are linked in the Binance Smart Chain.
  • Incentive: contributors are incentivized to donate tokens, so they can get a reward; it’s of common interest that funded environmental activities are actually completed.
  • Ease: for blockchain users it is very easy to use the ENV Finance fundraising system, it’s just a transaction from their wallet to the wallet of the project they want to fund.

WHY INVEST IN ENV FINANCE

NATURE

OUR PLANET CAN’T WAIT, AND WE NEED TO DO SOMETHING TO PROTECT IT. A HEALTHY ENVIRONMENTS MEANS A HEALTHY POPULATION.

INVEST

ENV TOKEN IS ALONG TERM INVESTMENT. THE CONTRIBUTIONS TO THE PROJECTS WILL GO BACK IN CONTRIBUTORS WALLETS WITH INCREASING REWARDS

STAKING

ENV FINANCE WILL DISTRIBUTE ENV TOKEN TO CONTRIBUTORS THAT STAKE THEIR TOKENS IN CONTRACTS LINKED TO SPECIFIC PROJECTS.


COMMUNITY

WE CANNOT MAKE THE DIFFERENCE ALONE, BUT A STRONG COMMUNITY IS A KEY POINT TO SUCCESS. TOGETHER.

TRANSPARENCY

BINANCE SMART CHAIN WILL PROVIDE A PUBLIC REGISTRY OF ALL THE TRANSACTIONS MADE BETWEEN CONTRIBUTORS AND PROJECTS.

TRUST

WE WANT TO BUILD A VERIFIED NETWORK OF INTERNATIONAL ORGANIZATIONS TO GIVE OUR USERS THE SAFETY FOR THEIR INVESTMENTS

Tokenomics

Max supply 123,000,000
Team 10% 12,300,000 (locked until 31-12-2021
Advisors & Early partners 20% 24,600,000
Initial liquidity 10% 12,300,000
Token sale 20% 24,600,000
Ecosystem (rewards and bonuses) 40% 49,200,000
Initial market supply: 1,000,000 (circulating supply will be increased by reward mechanism and listing on exchanges).

Reward mechanism

Contributors can choose a specific project to fund, and when it’s completely funded they will get a reward, based on time they have locked their funds into that project and on the amount. Rewards are diluted over time to prevent dumps on the market. On the other side, the collected funds are given in many steps to the organization that has proposed the project.

Partners

ENV Finance is building the network of organizations managing the environmental projects and activities, and has already found some international organizations who accepted to be hosted on the platform.

Team

Matteo Giacomelli
Co-Founder & CTO – Tech
Master Degree in IT & TLC Engineering
https://www.linkedin.com/in/matteo-giacomelli-08868842/
Lorenzo Corradini
Co-Founder & Head of Communication
Master degree in interfaces and communication technologies & social media manager
https://www.linkedin.com/in/lorenzo-corradini-2a63425b/
Alessandro Piffer
Co-Founder & renewable projects manager
Master degree in management and business consulting & supply chain management
https://www.linkedin.com/in/alessandro-piffer-a90226b4/
Alessandro Roat
Blockchain Expert
Master Degree in IT & TLC Engineering
https://www.linkedin.com/in/alexroat79

IDO/SALE

ENV Finance has chosen to distribute ENV token on DxSale platform, these the details of the sale:

Name: ENV Finance
Ticker: $ENV
Blockchain: BEP-20
Total Supply: 123,000,000
Presale:  https://dxsale.app/app/pages/defipresale?saleID=950&chain=BSC
LP: (60% of sale funds locked until 30-06-2023)
Soft Cap: 200 BNB
Hard Cap: 1000 BNB

Ido Sale Price: 1 BNB = 1,000
Listing Price: 1 BNB = 625

Minimum buy: 0.2 BNB
Maximum buy: 15 BNB

Start date: 11th April 18.00 UTC
End Date: 18th April 10.00 UTC

How and Where to Buy ENV Finance (ENV)?

ENV token is now live on the Binance mainnet. The token address for ENV is 0x4D2b1966F347E48B2d247F684d7677854083E4AB. Be cautious not to purchase any other token with a smart contract different from this one (as this can be easily faked). We strongly advise to be vigilant and stay safe throughout the launch. Don’t let the excitement get the best of you.

Just be sure you have enough BNB in your wallet to cover the transaction fees.

You will have to first buy one of the major cryptocurrencies, usually either Bitcoin (BTC), Ethereum (ETH), Tether (USDT), Binance (BNB)…

We will use Binance Exchange here as it is one of the largest crypto exchanges that accept fiat deposits.

Once you finished the KYC process. You will be asked to add a payment method. Here you can either choose to provide a credit/debit card or use a bank transfer, and buy one of the major cryptocurrencies, usually either Bitcoin (BTC), Ethereum (ETH), Tether (USDT), Binance (BNB)…

SIGN UP ON BINANCE

Step by Step Guide : What is Binance | How to Create an account on Binance (Updated 2021)

Next step

You need a wallet address to Connect to Pancakeswap Decentralized Exchange, we use Metamask wallet

If you don’t have a Metamask wallet, read this article and follow the steps

What is Metamask wallet | How to Create a wallet and Use

Transfer $WBNB to your new Metamask wallet from your existing wallet

Next step

Connect Metamask Wallet to Pancakeswap Decentralized Exchange and Buy, Swap ENV token

Contract: 0x4D2b1966F347E48B2d247F684d7677854083E4AB

There are a few popular crypto exchanges where they have decent daily trading volumes and a huge user base. This will ensure you will be able to sell your coins at any time and the fees will usually be lower. It is suggested that you also register on these exchanges since once ENV gets listed there it will attract a large amount of trading volumes from the users there, that means you will be having some great trading opportunities!

Top exchanges for token-coin trading. Follow instructions and make unlimited money

https://www.binance.com
 ☞ https://www.bittrex.com
 ☞ https://www.poloniex.com
 ☞ https://www.bitfinex.com
 ☞ https://www.huobi.com

Find more information ENV

Website:  http://env.finance
WhitePaper:  https://www.env.finance/pdf/whitepaper.pdf
Audit: https://www.env.finance/pdf/Env_Finance_Full_Smart_Contract_Security_Audit.pdf
FAQ:  http://env.finance/faq
Twitter:  twitter.com/env_finance
Telegram:  t.me/env_finance
GitHub:  https://github.com/ENVFinance
LinkedIn:  https://www.linkedin.com/company/env-finance
YouTube:  https://www.youtube.com/channel/UCo0MEOasz9izB793ZpUTiUQ

🔺DISCLAIMER: The Information in the post isn’t financial advice, is intended FOR GENERAL INFORMATION PURPOSES ONLY. Trading Cryptocurrency is VERY risky. Make sure you understand these risks and that you are responsible for what you do with your money.

🔥 If you’re a beginner. I believe the article below will be useful to you

⭐ ⭐ ⭐ What You Should Know Before Investing in Cryptocurrency - For Beginner ⭐ ⭐ ⭐

I hope this post will help you. Don’t forget to leave a like, comment and sharing it with others. Thank you!

#blockchain #env #env finance

What is ENV Finance (ENV) | What is ENV Finance token | What is ENV token

How To Get env Variable In Controller Or Blade File

In this tutorial i will give you information How To Get env Variable In Controller Or File many time we need to required of env variable in controller and blade file like if you are creating paypal integration then you have stored app id and secret key in env file.But if you haven’t any idea how to get it in controller or blade file.

So, let’s check how to get those variable data from .env file.

How To Get env Variable In Controller Or Blade File

https://websolutionstuff.com/post/how-to-get-env-variable-in-controller-or-blade-file

#laravel #laravel7 #laravel8 #blade #controller #env

How To Get env Variable In Controller Or Blade File