Gathering detailed insights and metrics for @goto-bus-stop/envify
Gathering detailed insights and metrics for @goto-bus-stop/envify
npm install @goto-bus-stop/envify
Typescript
Module System
Node Version
NPM Version
76
Supply Chain
99.4
Quality
73.9
Maintenance
100
Vulnerability
99.3
License
JavaScript (100%)
Total Downloads
830,383
Last Day
428
Last Week
2,172
Last Month
19,861
Last Year
261,173
3 Stars
86 Commits
2 Watching
1 Branches
26 Contributors
Latest Version
5.0.0
Package Id
@goto-bus-stop/envify@5.0.0
Size
3.19 kB
NPM Version
6.14.7
Node Version
14.7.0
Publised On
31 Jul 2020
Cumulative downloads
Total Downloads
Last day
44.6%
428
Compared to previous day
Last week
-45.4%
2,172
Compared to previous week
Last month
-53%
19,861
Compared to previous month
Last year
10.5%
261,173
Compared to previous year
4
This fork of envify supports modern JavaScript syntax.
Selectively replace Node-style environment variables with plain strings. Available as a standalone CLI tool and a Browserify v2 transform.
Works best in combination with uglifyify.
If you're using the module with Browserify:
1npm install @goto-bus-stop/envify browserify
Or, for the CLI:
1sudo npm install -g @goto-bus-stop/envify
envify will replace your environment variable checks with ordinary strings -
only the variables you use will be included, so you don't have to worry about,
say, AWS_SECRET_KEY
leaking through either. Take this example script:
1if (process.env.NODE_ENV === "development") { 2 console.log('development only') 3}
After running it through envify with NODE_ENV
set to production
, you'll
get this:
1if ("production" === "development") { 2 console.log('development only') 3}
By running this through a good minifier (e.g. terser), the above code would be stripped out completely.
However, if you bundled the same script with NODE_ENV
set to development
:
1if ("development" === "development") { 2 console.log('development only') 3}
The if
statement will evaluate to true
, so the code won't be removed.
With browserify:
1browserify index.js -t envify > bundle.js
Or standalone:
1envify index.js > bundle.js
You can also specify additional custom environment variables using browserify's subarg syntax, which is available in versions 3.25.0 and above:
1browserify index.js -t [ envify --NODE_ENV development ] > bundle.js 2browserify index.js -t [ envify --NODE_ENV production ] > bundle.js
require('envify')
Returns a transform stream that updates based on the Node process'
process.env
object.
require('envify/custom')([environment])
If you want to stay away from your environment variables, you can supply your own object to use in its place:
1var browserify = require('browserify') 2 , envify = require('envify/custom') 3 , fs = require('fs') 4 5var b = browserify('main.js') 6 , output = fs.createWriteStream('bundle.js') 7 8b.transform(envify({ 9 NODE_ENV: 'development' 10})) 11b.bundle().pipe(output)
process.env
By default, environment variables that are not defined will be left untouched. This is because in some cases, you might want to run an envify transform over your source more than once, and removing these values would make that impossible.
However, if any references to process.env
are remaining after transforming
your source with envify, browserify will automatically insert its shim for
Node's process object, which will increase the size of your bundle. This weighs
in at around 2KB, so if you're trying to be conservative with your bundle size
you can "purge" these remaining variables such that any missing ones are simply
replaced with undefined.
To do so through the command-line, simply use the subarg syntax and include
purge
after envify
, e.g.:
1browserify index.js -t [ envify purge --NODE_ENV development ]
Or if you're using the module API, you can pass _: "purge"
into your
arguments like so:
1b.transform(envify({ 2 _: 'purge' 3 , NODE_ENV: 'development' 4}))
No vulnerabilities found.
Reason
no binaries found in the repo
Reason
no dangerous workflow patterns detected
Reason
0 existing vulnerabilities detected
Reason
security policy file detected
Details
Reason
0 commit(s) and 0 issue activity found in the last 90 days -- score normalized to 0
Reason
Found 0/30 approved changesets -- score normalized to 0
Reason
no SAST tool detected
Details
Reason
dependency not pinned by hash detected -- score normalized to 0
Details
Reason
detected GitHub workflow tokens with excessive permissions
Details
Reason
no effort to earn an OpenSSF best practices badge detected
Reason
license file not detected
Details
Reason
project is not fuzzed
Details
Score
Last Scanned on 2024-12-30
The Open Source Security Foundation is a cross-industry collaboration to improve the security of open source software (OSS). The Scorecard provides security health metrics for open source projects.
Learn More