Gathering detailed insights and metrics for ember-cli-version-checker
Gathering detailed insights and metrics for ember-cli-version-checker
Gathering detailed insights and metrics for ember-cli-version-checker
Gathering detailed insights and metrics for ember-cli-version-checker
ember-cli-dependency-checker
Ember CLI addon for detecting missing npm and bower dependencies before executing ember commands
fork-ts-checker-webpack-plugin
Runs typescript type checker and linter on separate process.
ember-cli-app-version
Adds App version number to Ember Inspector Info Tab
ember-cli-htmlbars
A library for adding htmlbars to ember CLI
Dependency version checker for Ember CLI addons
npm install ember-cli-version-checker
Module System
Min. Node Version
Typescript Support
Node Version
NPM Version
24 Stars
353 Commits
22 Forks
9 Watching
14 Branches
35 Contributors
Updated on 03 Aug 2021
JavaScript (100%)
Cumulative downloads
Total Downloads
Last day
-17.4%
167,754
Compared to previous day
Last week
-9.8%
889,706
Compared to previous week
Last month
20.5%
4,068,878
Compared to previous month
Last year
26.4%
51,439,672
Compared to previous year
Makes it easier to determine if a compatible version of a given NPM package is present.
Example:
You want to provide two different sets of templates, based on the currently running Ember version.
1let path = require('path'); 2let VersionChecker = require('ember-cli-version-checker'); 3 4module.exports = { 5 name: 'awesome-addon', 6 treeForAddonTemplates(tree) { 7 let checker = new VersionChecker(this.project); 8 let dep = checker.for('ember-source'); 9 10 let baseTemplatesPath = path.join(this.root, 'addon/templates'); 11 12 if (dep.satisfies('>= 3.4.0')) { 13 return this.treeGenerator(path.join(baseTemplatesPath, 'current')); 14 } else { 15 return this.treeGenerator(path.join(baseTemplatesPath, 'legacy')); 16 } 17 } 18};
See https://github.com/npm/node-semver#comparison and https://github.com/npm/node-semver#ranges-1 for more info
1let VersionChecker = require('ember-cli-version-checker'); 2 3module.exports = { 4 name: 'awesome-addon', 5 init() { 6 this._super.init.apply(this, arguments); 7 8 let checker = new VersionChecker(this.project); 9 let dep = checker.for('ember-cli'); 10 11 if (dep.gte('2.0.0')) { 12 /* deal with 2.0.0+ stuff */ 13 } else { 14 /* provide backwards compat */ 15 }; 16 } 17};
Throws an error with the given message if a minimum version isn't met.
1let VersionChecker = require('ember-cli-version-checker'); 2 3module.exports = { 4 name: 'awesome-addon', 5 init() { 6 this._super.init.apply(this, arguments); 7 8 let checker = new VersionChecker(this.project); 9 10 checker.for('ember-cli').assertAbove('2.0.0'); 11 } 12};
You can also provide a specific message as the third argument to assertAbove
if you'd like to customize the output.
1let VersionChecker = require('ember-cli-version-checker'); 2 3module.exports = { 4 name: 'awesome-addon', 5 init() { 6 this._super.init.apply(this, arguments); 7 8 let checker = new VersionChecker(this.project); 9 10 checker.for('ember-cli').assertAbove('2.0.0', 'To use awesome-addon you must have ember-cli 2.0.0'); 11 } 12};
Returns true
if the packages version is above the specified comparison range.
1let VersionChecker = require('ember-cli-version-checker'); 2 3module.exports = { 4 name: 'awesome-addon', 5 init() { 6 this._super.init.apply(this, arguments); 7 8 let checker = new VersionChecker(this.project); 9 let dep = checker.for('ember-cli'); 10 11 if (dep.isAbove('2.0.0')) { 12 /* deal with 2.0.0 stuff */ 13 } else { 14 /* provide backwards compat */ 15 }; 16 } 17};
Returns true
or false
indicating if the dependency exists (at any version).
1let VersionChecker = require('ember-cli-version-checker'); 2 3module.exports = { 4 name: 'awesome-addon', 5 init() { 6 this._super.init.apply(this, arguments); 7 8 let checker = new VersionChecker(this.project); 9 let dep = checker.for('ember-cli-qunit'); 10 11 if (dep.exists()) { 12 /* do things when present */ 13 }; 14 } 15};
A property that returns the version for the dependency, if the dependency is not found
undefined
will be returned.
1let VersionChecker = require('ember-cli-version-checker'); 2 3module.exports = { 4 name: 'awesome-addon', 5 init() { 6 this._super.init.apply(this, arguments); 7 8 let checker = new VersionChecker(this.project); 9 let dep = checker.for('ember-cli-qunit'); 10 11 // do something with dep.version 12 } 13};
Returns true
if there is only single implementation in node_modules of the
addon. It can either be at app top-level or as a nested dependency. This API
does not work with non-addon npm dependency.
A unique addon can still be included multiple times if it's a nested dependency, but they are guaranteed to be resolved to same version in node_modules. This happens when the dependency in problem specifies a valid version range or the app uses yarn resolutions.
This is useful if the app wants to make sure there's no unexpected assets from the addon being included but still allow the addon to be included in the hierarchy's build process.
1const VersionChecker = require('ember-cli-version-checker'); 2 3module.exports = { 4 name: 'awesome-addon', 5 included() { 6 this._super.included.apply(this, arguments); 7 8 let checker = VersionChecker.forProject(this.project); 9 10 if (checker.hasSingleImplementation('<my-addon>')) { 11 /* do things when <my-addon> is unique */ 12 } 13 } 14};
Throws an error if the addon isn't unique, and receives an optional message param to customize the error message.
1const VersionChecker = require('ember-cli-version-checker');
2
3module.exports = {
4 name: 'awesome-addon',
5 included() {
6 this._super.included.apply(this, arguments);
7
8 let checker = VersionChecker.forProject(this.project);
9
10 checker.assertSingleImplementation('<my-addon>', 'Please make sure <my-addon> has only one implementation, please correct and here is a helpful message!');
11 }
12};
Find all addon instances with the same name
1const VersionChecker = require('ember-cli-version-checker'); 2 3module.exports = { 4 name: 'awesome-addon', 5 included() { 6 this._super.included.apply(this, arguments); 7 8 let checker = VersionChecker.forProject(this.project); 9 10 checker.filterAddonsByName('<my-addon>'); // => an array of addon instances who have the name `<my-addon>` 11 } 12};
An iterator which gives access to all addon instances
1const VersionChecker = require('ember-cli-version-checker'); 2 3module.exports = { 4 name: 'awesome-addon', 5 included() { 6 this._super.included.apply(this, arguments); 7 8 let checker = VersionChecker.forProject(this.project); 9 10 for (let { name, root } = checker.allAddons()) { 11 // access to the addon, in this case name and root 12 } 13 } 14};
A utility to verify that addons are installed at appropriate versions. npm
and yarn
resolve conflicting transitive dependency requirements by installing
multiple versions. They do not include a mechanism for packages to declare
that a dependency must be unique. This is, however, a practical constraint
when building Ember applications (for example, we would not want to build an
application that shipped two versions of Ember Data). Related discussion on npm
Every addon in the ember ecosystem implicitly depends on ember-source
, and
most likely a specific version range. If that dependency is specified as a
package.json
dependency, a mismatch between application and addon would
result in duplicating ember-source
. Instead of failing the build, we would
build an application with an unknown version of ember-source
, subverting the
point of specifying dependency version ranges in the first place! The check
API provides a mechanism to avoid this and fail fast in the build step, instead
of building an invalid application with harder to debug runtime errors.
For example, as of today ember-data
supports ember-source
>= 3.4.8
, if it
where to use this addon, it could specify this constraint and provide good
error messages to users.
1const VersionChecker = require('ember-cli-version-checker'); 2 3module.exports = { 4 name: 'awesome-addon', 5 included() { 6 this._super.included.apply(this, arguments); 7 8 const checker = VersionChecker.forProject(this.project); 9 const check = checker.check({ 10 'ember-source': '>= 3.4.8' 11 }); 12 13 // if it would like to simply assert 14 check.assert('[awesome-addon] dependency check failed'); 15 // will throw an error message similar to the following if the check was not satisfied: 16 17 // [awesome-addon] dependency check failed: 18 // - 'ember-source' expected version [>= 3.4.8] but got version: [2.0.0] 19 20 // if the requirements are more advanced, we can inspect the resulting check. 21 22 if (!check.isSatisfied) { 23 const altCheck = checker.check({ 24 'magical-polyfil': '>= 1.0.0', 25 'ember-source': '>= 3.0.0' 26 }) 27 28 check.assert('[awesome-addon] dependency check failed:'); 29 // will throw error message similar to the following if the check was not satisfied: 30 // [awesome-addon] dependency check failed: 31 // - 'magical-polyfil' expected version [>= 1.0.0] but got version: [0.0.1] 32 // - 'ember-source' expected version [>= 3.0.0] but got version: [2.0.-] 33 } 34 } 35};
When creating VersionChecker(addonOrAppOrProject)
, the param needs to have a root
property for the VersionChecker to perform node's
module resolution.
The two primary options that are valid are:
new VersionChecker(this.project)
new VersionChecker(this.parent)
Which one to use depends on if the addon is trying to find a known top-level library or its parent's.
For example, you may want to check this.project
root path to find ember-cli
or ember-source
,
which are expected to be top-level.
Or you may want to check your parent's specific dependency that affects your addon's behavior, you should create
from this.parent
.
If you create via new VersionChecker(this)
in an addon, it will resolve from your addon's path and have your
own dependency's version instead of top-level dependency's if exists. This will result in unreliable result.
No vulnerabilities found.
Reason
no dangerous workflow patterns detected
Reason
no binaries found in the repo
Reason
Found 3/25 approved changesets -- score normalized to 1
Reason
0 commit(s) and 0 issue activity found in the last 90 days -- score normalized to 0
Reason
detected GitHub workflow tokens with excessive permissions
Details
Reason
dependency not pinned by hash detected -- score normalized to 0
Details
Reason
no effort to earn an OpenSSF best practices badge detected
Reason
project is not fuzzed
Details
Reason
license file not detected
Details
Reason
branch protection not enabled on development/release branches
Details
Reason
security policy file not detected
Details
Reason
SAST tool is not run on all commits -- score normalized to 0
Details
Reason
34 existing vulnerabilities detected
Details
Score
Last Scanned on 2024-11-25
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