fastify-file-routes icon indicating copy to clipboard operation
fastify-file-routes copied to clipboard

Published 20 hours ago • verified publisher icon spa5k

chore(deps): update dependency dotenv to v16.5.0

Open renovate[bot] opened this issue 2 years ago • 7 comments

This PR contains the following updates:

Package Change Age Adoption Passing Confidence
dotenv 16.0.0 -> 16.5.0 age adoption passing confidence

Release Notes

motdotla/dotenv (dotenv)

v16.5.0

Compare Source

Added
  • 🎉 Added new sponsor Graphite - the AI developer productivity platform helping teams on GitHub ship higher quality software, faster.

[!TIP] Become a sponsor

The dotenvx README is viewed thousands of times DAILY on GitHub and NPM. Sponsoring dotenv is a great way to get in front of developers and give back to the developer community at the same time.

Changed
  • Remove _log method. Use _debug #​862

v16.4.7

Compare Source

Changed
  • Ignore .tap folder when publishing. (oops, sorry about that everyone. - @​motdotla) #​848

v16.4.6

Compare Source

Changed
  • Clean up stale dev dependencies #​847
  • Various README updates clarifying usage and alternative solutions using dotenvx

v16.4.5

Compare Source

Changed
  • 🐞 Fix recent regression when using path option. return to historical behavior: do not attempt to auto find .env if path set. (regression was introduced in 16.4.3) #​814

v16.4.4

Compare Source

Changed
  • 🐞 Replaced chaining operator ?. with old school && (fixing node 12 failures) #​812

v16.4.3

Compare Source

Changed
  • Fixed processing of multiple files in options.path #​805

v16.4.2

Compare Source

Changed

v16.4.1

Compare Source

  • Patch support for array as path option #​797

v16.4.0

Compare Source

  • Add error.code to error messages around .env.vault decryption handling #​795
  • Add ability to find .env.vault file when filename(s) passed as an array #​784

v16.3.2

Compare Source

Added
  • Add debug message when no encoding set #​735
Changed
  • Fix output typing for populate #​792
  • Use subarray instead of slice #​793

v16.3.1

Compare Source

Added
  • Add missing type definitions for processEnv and DOTENV_KEY options. #​756

v16.3.0

Compare Source

Added
  • Optionally pass DOTENV_KEY to options rather than relying on process.env.DOTENV_KEY. Defaults to process.env.DOTENV_KEY #​754

v16.2.0

Compare Source

Added
  • Optionally write to your own target object rather than process.env. Defaults to process.env. #​753
  • Add import type URL to types file #​751

v16.1.4

Compare Source

Added
  • Added .github/ to .npmignore #​747

v16.1.3

Compare Source

Removed
  • Removed browser keys for path, os, and crypto in package.json. These were set to false incorrectly as of 16.1. Instead, if using dotenv on the front-end make sure to include polyfills for path, os, and crypto. node-polyfill-webpack-plugin provides these.

v16.1.2

Compare Source

Changed
  • Exposed private function _configDotenv as configDotenv. #​744

v16.1.1

Compare Source

Added
  • Added type definition for decrypt function
Changed
  • Fixed {crypto: false} in packageJson.browser

v16.1.0

Compare Source

Added
  • Add populate convenience method #​733
  • Accept URL as path option #​720
  • Add dotenv to npm fund command
  • Spanish language README #​698
  • Add .env.vault support. 🎉 (#​730)

ℹ️ .env.vault extends the .env file format standard with a localized encrypted vault file. Package it securely with your production code deploys. It's cloud agnostic so that you can deploy your secrets anywhere – without risky third-party integrations. read more

Changed
  • Fixed "cannot resolve 'fs'" error on tools like Replit #​693

v16.0.3

Compare Source

Changed
  • Added library version to debug logs (#​682)

v16.0.2

Compare Source

Added
  • Export env-options.js and cli-options.js in package.json for use with downstream dotenv-expand module

v16.0.1

Compare Source

Changed
  • Minor README clarifications
  • Development ONLY: updated devDependencies as recommended for development only security risks (#​658)

Configuration

📅 Schedule: Branch creation - "every month" (UTC), Automerge - At any time (no schedule defined).

🚦 Automerge: Enabled.

♻ Rebasing: Whenever PR is behind base branch, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.

  • [ ] If you want to rebase/retry this PR, check this box

This PR was generated by Mend Renovate. View the repository job log.

renovate[bot] avatar Jun 01 '23 02:06 renovate[bot]

⚠ Artifact update problem

Renovate failed to update an artifact related to this branch. You probably do not want to merge this PR as-is.

♻ Renovate will retry this branch, including artifacts, only when one of the following happens:

  • any of the package files in this branch needs updating, or
  • the branch becomes conflicted, or
  • you click the rebase/retry checkbox if found above, or
  • you rename this PR's title to start with "rebase!" to trigger it manually

The artifact failure details are included below:

File name: pnpm-lock.yaml
 WARN  The "store" setting has been renamed to "store-dir". Please use the new name.
 WARN  GET https://registry.npmjs.org/@commitlint/cli/-/cli-16.2.1.tgz error (ERR_INVALID_THIS). Will retry in 10 seconds. 2 retries left.
 WARN  GET https://registry.npmjs.org/@commitlint/config-conventional/-/config-conventional-16.2.1.tgz error (ERR_INVALID_THIS). Will retry in 10 seconds. 2 retries left.
 WARN  GET https://registry.npmjs.org/@semantic-release/changelog/-/changelog-6.0.1.tgz error (ERR_INVALID_THIS). Will retry in 10 seconds. 2 retries left.
 WARN  GET https://registry.npmjs.org/@semantic-release/commit-analyzer/-/commit-analyzer-9.0.2.tgz error (ERR_INVALID_THIS). Will retry in 10 seconds. 2 retries left.
 WARN  GET https://registry.npmjs.org/@semantic-release/git/-/git-10.0.1.tgz error (ERR_INVALID_THIS). Will retry in 10 seconds. 2 retries left.
 WARN  GET https://registry.npmjs.org/@semantic-release/github/-/github-8.0.2.tgz error (ERR_INVALID_THIS). Will retry in 10 seconds. 2 retries left.
 WARN  GET https://registry.npmjs.org/@semantic-release/npm/-/npm-9.0.1.tgz error (ERR_INVALID_THIS). Will retry in 10 seconds. 2 retries left.
 WARN  GET https://registry.npmjs.org/@semantic-release/release-notes-generator/-/release-notes-generator-10.0.3.tgz error (ERR_INVALID_THIS). Will retry in 10 seconds. 2 retries left.
 WARN  GET https://registry.npmjs.org/@spa5k/eslint-config/-/eslint-config-0.0.2.tgz error (ERR_INVALID_THIS). Will retry in 10 seconds. 2 retries left.
 WARN  GET https://registry.npmjs.org/@types/jest/-/jest-27.4.1.tgz error (ERR_INVALID_THIS). Will retry in 10 seconds. 2 retries left.
 WARN  GET https://registry.npmjs.org/@types/node/-/node-17.0.21.tgz error (ERR_INVALID_THIS). Will retry in 10 seconds. 2 retries left.
 WARN  GET https://registry.npmjs.org/@typescript-eslint/eslint-plugin/-/eslint-plugin-5.14.0.tgz error (ERR_INVALID_THIS). Will retry in 10 seconds. 2 retries left.
 WARN  GET https://registry.npmjs.org/@typescript-eslint/parser/-/parser-5.14.0.tgz error (ERR_INVALID_THIS). Will retry in 10 seconds. 2 retries left.
 WARN  GET https://registry.npmjs.org/c8/-/c8-7.11.0.tgz error (ERR_INVALID_THIS). Will retry in 10 seconds. 2 retries left.
 WARN  GET https://registry.npmjs.org/commitizen/-/commitizen-4.2.4.tgz error (ERR_INVALID_THIS). Will retry in 10 seconds. 2 retries left.
 WARN  GET https://registry.npmjs.org/dotenv error (ERR_INVALID_THIS). Will retry in 10 seconds. 2 retries left.
 WARN  GET https://registry.npmjs.org/@commitlint/cli/-/cli-16.2.1.tgz error (ERR_INVALID_THIS). Will retry in 1 minute. 1 retries left.
 WARN  GET https://registry.npmjs.org/@commitlint/config-conventional/-/config-conventional-16.2.1.tgz error (ERR_INVALID_THIS). Will retry in 1 minute. 1 retries left.
 WARN  GET https://registry.npmjs.org/@semantic-release/changelog/-/changelog-6.0.1.tgz error (ERR_INVALID_THIS). Will retry in 1 minute. 1 retries left.
 WARN  GET https://registry.npmjs.org/@semantic-release/commit-analyzer/-/commit-analyzer-9.0.2.tgz error (ERR_INVALID_THIS). Will retry in 1 minute. 1 retries left.
 WARN  GET https://registry.npmjs.org/@semantic-release/git/-/git-10.0.1.tgz error (ERR_INVALID_THIS). Will retry in 1 minute. 1 retries left.
 WARN  GET https://registry.npmjs.org/@semantic-release/github/-/github-8.0.2.tgz error (ERR_INVALID_THIS). Will retry in 1 minute. 1 retries left.
 WARN  GET https://registry.npmjs.org/@semantic-release/npm/-/npm-9.0.1.tgz error (ERR_INVALID_THIS). Will retry in 1 minute. 1 retries left.
 WARN  GET https://registry.npmjs.org/@semantic-release/release-notes-generator/-/release-notes-generator-10.0.3.tgz error (ERR_INVALID_THIS). Will retry in 1 minute. 1 retries left.
 WARN  GET https://registry.npmjs.org/@spa5k/eslint-config/-/eslint-config-0.0.2.tgz error (ERR_INVALID_THIS). Will retry in 1 minute. 1 retries left.
 WARN  GET https://registry.npmjs.org/@types/jest/-/jest-27.4.1.tgz error (ERR_INVALID_THIS). Will retry in 1 minute. 1 retries left.
 WARN  GET https://registry.npmjs.org/@types/node/-/node-17.0.21.tgz error (ERR_INVALID_THIS). Will retry in 1 minute. 1 retries left.
 WARN  GET https://registry.npmjs.org/@typescript-eslint/eslint-plugin/-/eslint-plugin-5.14.0.tgz error (ERR_INVALID_THIS). Will retry in 1 minute. 1 retries left.
 WARN  GET https://registry.npmjs.org/@typescript-eslint/parser/-/parser-5.14.0.tgz error (ERR_INVALID_THIS). Will retry in 1 minute. 1 retries left.
 WARN  GET https://registry.npmjs.org/c8/-/c8-7.11.0.tgz error (ERR_INVALID_THIS). Will retry in 1 minute. 1 retries left.
 WARN  GET https://registry.npmjs.org/commitizen/-/commitizen-4.2.4.tgz error (ERR_INVALID_THIS). Will retry in 1 minute. 1 retries left.
 WARN  GET https://registry.npmjs.org/dotenv error (ERR_INVALID_THIS). Will retry in 1 minute. 1 retries left.
 WARN  GET https://registry.npmjs.org/eslint/-/eslint-8.10.0.tgz error (ERR_INVALID_THIS). Will retry in 10 seconds. 2 retries left.
undefined
 ERR_INVALID_THIS  Value of "this" must be of type URLSearchParams
 WARN  GET https://registry.npmjs.org/eslint-config-galex/-/eslint-config-galex-3.6.5.tgz error (ERR_INVALID_THIS). Will retry in 10 seconds. 2 retries left.

renovate[bot] avatar Dec 16 '23 03:12 renovate[bot]

This PR has 2 quantified lines of changes. In general, a change size of upto 200 lines is ideal for the best PR experience!

Quantification details 

Label      : Extra Small
Size       : +1 -1
Percentile : 0.8%

Total files changed: 1

Change summary by file extension:
.json : +1 -1

Change counts above are quantified counts, based on the PullRequestQuantifier customizations.

Why proper sizing of changes matters

Optimal pull request sizes drive a better predictable PR flow as they strike a balance between between PR complexity and PR review overhead. PRs within the optimal size (typical small, or medium sized PRs) mean:

  • Fast and predictable releases to production:
    • Optimal size changes are more likely to be reviewed faster with fewer iterations.
    • Similarity in low PR complexity drives similar review times.
  • Review quality is likely higher as complexity is lower:
    • Bugs are more likely to be detected.
    • Code inconsistencies are more likely to be detected.
  • Knowledge sharing is improved within the participants:
    • Small portions can be assimilated better.
  • Better engineering practices are exercised:
    • Solving big problems by dividing them in well contained, smaller problems.
    • Exercising separation of concerns within the code changes.

What can I do to optimize my changes

  • Use the PullRequestQuantifier to quantify your PR accurately
    • Create a context profile for your repo using the context generator
    • Exclude files that are not necessary to be reviewed or do not increase the review complexity. Example: Autogenerated code, docs, project IDE setting files, binaries, etc. Check out the Excluded section from your prquantifier.yaml context profile.
    • Understand your typical change complexity, drive towards the desired complexity by adjusting the label mapping in your prquantifier.yaml context profile.
    • Only use the labels that matter to you, see context specification to customize your prquantifier.yaml context profile.
  • Change your engineering behaviors
    • For PRs that fall outside of the desired spectrum, review the details and check if:
      • Your PR could be split in smaller, self-contained PRs instead
      • Your PR only solves one particular issue. (For example, don't refactor and code new features in the same PR).

How to interpret the change counts in git diff output

  • One line was added: +1 -0
  • One line was deleted: +0 -1
  • One line was modified: +1 -1 (git diff doesn't know about modified, it will interpret that line like one addition plus one deletion)
  • Change percentiles: Change characteristics (addition, deletion, modification) of this PR in relation to all other PRs within the repository.

Was this comment helpful? :thumbsup:  :ok_hand:  :thumbsdown: (Email) Customize PullRequestQuantifier for this repository.

pull-request-quantifier-deprecated[bot] avatar Jan 24 '24 21:01 pull-request-quantifier-deprecated[bot]

This PR has 2 quantified lines of changes. In general, a change size of upto 200 lines is ideal for the best PR experience!

Quantification details 

Label      : Extra Small
Size       : +1 -1
Percentile : 0.8%

Total files changed: 1

Change summary by file extension:
.json : +1 -1

Change counts above are quantified counts, based on the PullRequestQuantifier customizations.

Why proper sizing of changes matters

Optimal pull request sizes drive a better predictable PR flow as they strike a balance between between PR complexity and PR review overhead. PRs within the optimal size (typical small, or medium sized PRs) mean:

  • Fast and predictable releases to production:
    • Optimal size changes are more likely to be reviewed faster with fewer iterations.
    • Similarity in low PR complexity drives similar review times.
  • Review quality is likely higher as complexity is lower:
    • Bugs are more likely to be detected.
    • Code inconsistencies are more likely to be detected.
  • Knowledge sharing is improved within the participants:
    • Small portions can be assimilated better.
  • Better engineering practices are exercised:
    • Solving big problems by dividing them in well contained, smaller problems.
    • Exercising separation of concerns within the code changes.

What can I do to optimize my changes

  • Use the PullRequestQuantifier to quantify your PR accurately
    • Create a context profile for your repo using the context generator
    • Exclude files that are not necessary to be reviewed or do not increase the review complexity. Example: Autogenerated code, docs, project IDE setting files, binaries, etc. Check out the Excluded section from your prquantifier.yaml context profile.
    • Understand your typical change complexity, drive towards the desired complexity by adjusting the label mapping in your prquantifier.yaml context profile.
    • Only use the labels that matter to you, see context specification to customize your prquantifier.yaml context profile.
  • Change your engineering behaviors
    • For PRs that fall outside of the desired spectrum, review the details and check if:
      • Your PR could be split in smaller, self-contained PRs instead
      • Your PR only solves one particular issue. (For example, don't refactor and code new features in the same PR).

How to interpret the change counts in git diff output

  • One line was added: +1 -0
  • One line was deleted: +0 -1
  • One line was modified: +1 -1 (git diff doesn't know about modified, it will interpret that line like one addition plus one deletion)
  • Change percentiles: Change characteristics (addition, deletion, modification) of this PR in relation to all other PRs within the repository.

Was this comment helpful? :thumbsup:  :ok_hand:  :thumbsdown: (Email) Customize PullRequestQuantifier for this repository.

pull-request-quantifier-deprecated[bot] avatar Feb 10 '24 22:02 pull-request-quantifier-deprecated[bot]

This PR has 2 quantified lines of changes. In general, a change size of upto 200 lines is ideal for the best PR experience!

Quantification details 

Label      : Extra Small
Size       : +1 -1
Percentile : 0.8%

Total files changed: 1

Change summary by file extension:
.json : +1 -1

Change counts above are quantified counts, based on the PullRequestQuantifier customizations.

Why proper sizing of changes matters

Optimal pull request sizes drive a better predictable PR flow as they strike a balance between between PR complexity and PR review overhead. PRs within the optimal size (typical small, or medium sized PRs) mean:

  • Fast and predictable releases to production:
    • Optimal size changes are more likely to be reviewed faster with fewer iterations.
    • Similarity in low PR complexity drives similar review times.
  • Review quality is likely higher as complexity is lower:
    • Bugs are more likely to be detected.
    • Code inconsistencies are more likely to be detected.
  • Knowledge sharing is improved within the participants:
    • Small portions can be assimilated better.
  • Better engineering practices are exercised:
    • Solving big problems by dividing them in well contained, smaller problems.
    • Exercising separation of concerns within the code changes.

What can I do to optimize my changes

  • Use the PullRequestQuantifier to quantify your PR accurately
    • Create a context profile for your repo using the context generator
    • Exclude files that are not necessary to be reviewed or do not increase the review complexity. Example: Autogenerated code, docs, project IDE setting files, binaries, etc. Check out the Excluded section from your prquantifier.yaml context profile.
    • Understand your typical change complexity, drive towards the desired complexity by adjusting the label mapping in your prquantifier.yaml context profile.
    • Only use the labels that matter to you, see context specification to customize your prquantifier.yaml context profile.
  • Change your engineering behaviors
    • For PRs that fall outside of the desired spectrum, review the details and check if:
      • Your PR could be split in smaller, self-contained PRs instead
      • Your PR only solves one particular issue. (For example, don't refactor and code new features in the same PR).

How to interpret the change counts in git diff output

  • One line was added: +1 -0
  • One line was deleted: +0 -1
  • One line was modified: +1 -1 (git diff doesn't know about modified, it will interpret that line like one addition plus one deletion)
  • Change percentiles: Change characteristics (addition, deletion, modification) of this PR in relation to all other PRs within the repository.

Was this comment helpful? :thumbsup:  :ok_hand:  :thumbsdown: (Email) Customize PullRequestQuantifier for this repository.

pull-request-quantifier-deprecated[bot] avatar Feb 12 '24 21:02 pull-request-quantifier-deprecated[bot]

This PR has 2 quantified lines of changes. In general, a change size of upto 200 lines is ideal for the best PR experience!

Quantification details 

Label      : Extra Small
Size       : +1 -1
Percentile : 0.8%

Total files changed: 1

Change summary by file extension:
.json : +1 -1

Change counts above are quantified counts, based on the PullRequestQuantifier customizations.

Why proper sizing of changes matters

Optimal pull request sizes drive a better predictable PR flow as they strike a balance between between PR complexity and PR review overhead. PRs within the optimal size (typical small, or medium sized PRs) mean:

  • Fast and predictable releases to production:
    • Optimal size changes are more likely to be reviewed faster with fewer iterations.
    • Similarity in low PR complexity drives similar review times.
  • Review quality is likely higher as complexity is lower:
    • Bugs are more likely to be detected.
    • Code inconsistencies are more likely to be detected.
  • Knowledge sharing is improved within the participants:
    • Small portions can be assimilated better.
  • Better engineering practices are exercised:
    • Solving big problems by dividing them in well contained, smaller problems.
    • Exercising separation of concerns within the code changes.

What can I do to optimize my changes

  • Use the PullRequestQuantifier to quantify your PR accurately
    • Create a context profile for your repo using the context generator
    • Exclude files that are not necessary to be reviewed or do not increase the review complexity. Example: Autogenerated code, docs, project IDE setting files, binaries, etc. Check out the Excluded section from your prquantifier.yaml context profile.
    • Understand your typical change complexity, drive towards the desired complexity by adjusting the label mapping in your prquantifier.yaml context profile.
    • Only use the labels that matter to you, see context specification to customize your prquantifier.yaml context profile.
  • Change your engineering behaviors
    • For PRs that fall outside of the desired spectrum, review the details and check if:
      • Your PR could be split in smaller, self-contained PRs instead
      • Your PR only solves one particular issue. (For example, don't refactor and code new features in the same PR).

How to interpret the change counts in git diff output

  • One line was added: +1 -0
  • One line was deleted: +0 -1
  • One line was modified: +1 -1 (git diff doesn't know about modified, it will interpret that line like one addition plus one deletion)
  • Change percentiles: Change characteristics (addition, deletion, modification) of this PR in relation to all other PRs within the repository.

Was this comment helpful? :thumbsup:  :ok_hand:  :thumbsdown: (Email) Customize PullRequestQuantifier for this repository.

pull-request-quantifier-deprecated[bot] avatar Feb 13 '24 19:02 pull-request-quantifier-deprecated[bot]

This PR has 2 quantified lines of changes. In general, a change size of upto 200 lines is ideal for the best PR experience!

Quantification details 

Label      : Extra Small
Size       : +1 -1
Percentile : 0.8%

Total files changed: 1

Change summary by file extension:
.json : +1 -1

Change counts above are quantified counts, based on the PullRequestQuantifier customizations.

Why proper sizing of changes matters

Optimal pull request sizes drive a better predictable PR flow as they strike a balance between between PR complexity and PR review overhead. PRs within the optimal size (typical small, or medium sized PRs) mean:

  • Fast and predictable releases to production:
    • Optimal size changes are more likely to be reviewed faster with fewer iterations.
    • Similarity in low PR complexity drives similar review times.
  • Review quality is likely higher as complexity is lower:
    • Bugs are more likely to be detected.
    • Code inconsistencies are more likely to be detected.
  • Knowledge sharing is improved within the participants:
    • Small portions can be assimilated better.
  • Better engineering practices are exercised:
    • Solving big problems by dividing them in well contained, smaller problems.
    • Exercising separation of concerns within the code changes.

What can I do to optimize my changes

  • Use the PullRequestQuantifier to quantify your PR accurately
    • Create a context profile for your repo using the context generator
    • Exclude files that are not necessary to be reviewed or do not increase the review complexity. Example: Autogenerated code, docs, project IDE setting files, binaries, etc. Check out the Excluded section from your prquantifier.yaml context profile.
    • Understand your typical change complexity, drive towards the desired complexity by adjusting the label mapping in your prquantifier.yaml context profile.
    • Only use the labels that matter to you, see context specification to customize your prquantifier.yaml context profile.
  • Change your engineering behaviors
    • For PRs that fall outside of the desired spectrum, review the details and check if:
      • Your PR could be split in smaller, self-contained PRs instead
      • Your PR only solves one particular issue. (For example, don't refactor and code new features in the same PR).

How to interpret the change counts in git diff output

  • One line was added: +1 -0
  • One line was deleted: +0 -1
  • One line was modified: +1 -1 (git diff doesn't know about modified, it will interpret that line like one addition plus one deletion)
  • Change percentiles: Change characteristics (addition, deletion, modification) of this PR in relation to all other PRs within the repository.

Was this comment helpful? :thumbsup:  :ok_hand:  :thumbsdown: (Email) Customize PullRequestQuantifier for this repository.

pull-request-quantifier-deprecated[bot] avatar Feb 20 '24 07:02 pull-request-quantifier-deprecated[bot]