6 | {props.constraint.constraint} is a hyphen constraint. It means that it will match{' '}
7 | several versions.
8 |
8 | {props.constraint.constraint} is a caret constraint. It means that it will
9 | match several versions.
10 |
7 | {props.children} 8 | 9 | 12 |13 | ); 14 | 15 | Quote.propTypes = { 16 | className: PropTypes.string, 17 | author: PropTypes.string.isRequired, 18 | source: PropTypes.string.isRequired, 19 | children: PropTypes.oneOfType([PropTypes.arrayOf(PropTypes.node), PropTypes.node]).isRequired, 20 | }; 21 | 22 | Quote.defaultProps = { 23 | className: '', 24 | }; 25 | 26 | export default Quote; 27 | -------------------------------------------------------------------------------- /src/components/Explain.js: -------------------------------------------------------------------------------- 1 | import React from 'react'; 2 | import PropTypes from 'prop-types'; 3 | import { connect } from 'react-redux'; 4 | import ExplainConstraint from './ExplainConstraint'; 5 | import ExplainVersion from './ExplainVersion'; 6 | 7 | export const Explain = props => ( 8 |
8 | {props.constraint.constraint} is a pessimistic constraint. It means that it
9 | will match several versions.
10 |
8 | {props.constraint.constraint} is a strict constraint. It means that it will
9 | match a single version.
10 |
9 | {props.constraint.constraint} is a x-range constraint. It means that it will
10 | match several versions.
11 |
Given the constraint you entered, you will get:
12 | 13 |
11 | {props.constraint.constraint} is a range constraint. It means that it will
12 | match several versions.
13 |
9 | {props.constraint.constraint} is a tilde constraint. It means that it will
10 | match several versions.
11 |
18 | Composer handles tilde constraint differently. Your constraint will translate to{' '}
19 |
20 | >=
21 | {props.constraint.semver.major}.{props.constraint.semver.minor}
22 | .0 <
23 | {parseInt(props.constraint.semver.major, 10) + 1}
24 | .0.0
25 |
26 | .
27 |
11 |18 | 19 |In the world of software management there exists a dread place called "dependency hell."
12 | 13 |14 | The bigger your system grows and the more packages you integrate into your software, the more likely 15 | you are to find yourself, one day, in this pit of despair. 16 |
17 |
20 | More and more projects try to follow Semantic Versioning to reduce package versioning nightmare and 21 | every dependency manager implements its own semantic versioner.{' '} 22 | Composer and NPM for example 23 | don't handle version constraints the same way. It's hard sometimes to be sure how some library version 24 | will behave against some constraint. 25 |
26 | 27 |This tiny webapp checks if a given version satisfies another given constraint.
28 |11 | Loose constraint are those constraints matching any version greater than a given one. It is a very bad 12 | idea to use them. 13 |
14 | 15 |16 | Why? Because with them you are only giving a lower bound to your dependency's version, which means every 17 | version greater than the one you chose, be it a patch, minor or major release. If we read Semantic 18 | Versioning carefully: 19 |
20 | 21 |22 |30 | 31 |23 |
29 |- 24 | Major version X (x.y.z | x > 0) MUST be incremented if any backwards incompatible changes are 25 | introduced to the public API. It MAY include minor and patch level changes. Patch and minor 26 | version MUST be reset to 0 when major version is incremented. 27 |
28 |
32 | What does this mean? It means that major releases may break backward compatibility. 33 | With a loose constraint you will get those releases and the BC break they introduce. This is likely not 34 | what you want! 35 |
36 |{props.version.version} satisfies constraint {props.constraint.constraint}
19 | {props.version.version} does not satisfy constraint{' '}
25 | {props.constraint.constraint}
26 | Given the version you entered:
30 | 31 |{semver.inc(props.version.version, type)}
36 | 10 | Semantic Versioning stands as a standard versioning scheme but it does not ( 11 | yet) cover dependency management and how to 12 | express constraint. 13 |
14 | 15 |
16 | Without any formal specification about constraint, dependency managers sometimes handle or express them
17 | differently. For example, the tilde-range constraint (~x.y) does not work the same way in{' '}
18 | NPM and Composer.
19 |
10 | Strict constraint (or fully qualified constraint) are those constraints matching only one version. In 11 | most case it is a bad idea to use them. 12 |
13 | 14 |15 | Why? Because with them you are locking your dependency to a specific patch release which means you won't 16 | ever get bug fixes when updating your dependencies. 17 |
18 | 19 |20 | Moreover, using strict constraint will make the work of some dependency managers harder: if you are 21 | depending on a package and have a dependency in common, if both of you require this common dependency 22 | strictly, your manager won't be able to choose an appropriate version, satisfying every constraint. 23 |
24 | 25 |Unless you know exactly what you are doing and why, you should change to a more flexible one like:
26 | 27 |~x.y.z if your dependency manager supports tilde-range constraints
30 | >=x.y.z <x.(y+1).0 if your dependency manager supports range constraints
33 | 37 | Using such constraints, you will allow your dependency manager to pull patch releases letting you get 38 | bug fixes. If the library you are depending on strictly implements Semantic Versioning you should be 39 | able to make your constraint even more flexible by allowing your dependency manager to also pull new 40 | features: 41 |
42 | 43 |^x.y.z if your dependency manager supports caret-range constraints
46 | >=x.y.z <(x+1).0.0 if your dependency manager support range constraints
49 | {props.constraint.semver.raw}.
33 |