env-dot-prop VS semver

env-dot-prop

We haven't tracked posts mentioning env-dot-prop yet.
Tracking mentions began in Dec 2020.

semver

• The curious case of semver
  2 projects | /r/coding | 8 May 2023

  Yeah, but it talks about the semver package, which is related and why it caused performance issues

• Release NPM Package With Automatic Versioning
  1 project | dev.to | 20 Sep 2022

  This release script increments the version number of the package and publishes the package to the NPM registry (or other registry). To correctly increment the version number, npm's semver package automatically finds the next version number according to the specified level minor (major/minor/patch).

• Symbols in package.json
  2 projects | dev.to | 6 Jun 2022

  In a later post, I shall be sharing some actual examples using node-semver, which is the tool that npm uses to parse these Semantic Versioning Complaint dependencies version.

• npm-registry-firewall
  1 project | dev.to | 13 Apr 2022

  { "server": { "host": "localhost", // Defaults to 127.0.0.1 "port": 3000, // 8080 by default "secure": { // Optional. If declared serves via https "cert": "ssl/cert.pem", "key": "ssl/key.pem" }, "base": "/", // Optional. Defaults to '/' "healthcheck": "/health", // Optional. Defaults to '/healthcheck'. Pass null to disable "keepAliveTimeout": 15000, // Optional. Defaults 61000 "headersTimeout": 20000, // Optional. Defaults 62000 "requestTimeout": 10000 // Optional. Defaults 30000 }, "firewall": { "registry": "https://registry.npmmirror.com", // Remote registry "entrypoint": "https://r.qiwi.com/npm", // Optional. Defaults to `${server.secure ? 'https' : 'http'}://${server.host}:${server.port}${route.base}` "base": "/", // Optional. Defaults to '/' "rules": [ { "policy": "allow", "org": "@qiwi" }, { "policy": "allow", "name": ["@babel/*", "@jest/*", "lodash"] // string[] or "comma,separated,list". * works as .+ in regexp }, { "policy": "deny", "name": "colors", "version": ">= v1.4.0" // Any semver range: https://github.com/npm/node-semver#ranges }, { "policy": "deny", "license": "dbad" // Comma-separated license types or string[] }, { "policy": "allow", "username": ["sindresorhus", "isaacs"] // Trusted npm authors. }, { "policy": "allow", "name": "d", // `allow` is upper, so it protects `< 1.0.0`-ranged versions that might be omitted on next steps "version": "< 1.0.0" }, { "policy": "deny", // Checks pkg version publish date against the range "dateRange": ["2010-01-01T00:00:00.000Z", "2025-01-01T00:00:00.000Z"] }, { "policy": "allow", "age": 5 // Check the package version is older than 5 days. Like quarantine } ] } }

• Package.json File explained!!!
  4 projects | dev.to | 30 Jun 2021

  Note: ~ and ^ you see in the dependency versions are notations for version ranges defined in semver as it follows semantic versioning.

• SemVer - 0.x.x
  3 projects | dev.to | 6 Apr 2021

  To prevent potential breaking changes, when you do a minor update of a dependency, NPM treats versions a bit different:

• One-stop shop for working with semantic versions in your GitHub Actions workflows
  3 projects | dev.to | 30 Mar 2021

  Yeah, it's basically a wapper around semver package, so the outputs may look familiar to you. But if you need more in your workflows — feel free to open an issue with a feature you’re missing.