Gathering detailed insights and metrics for ember-try
Gathering detailed insights and metrics for ember-try
Gathering detailed insights and metrics for ember-try
Gathering detailed insights and metrics for ember-try
ember-try-config
Configuration generator for ember-try
ember-addon-try
The default blueprint for ember-cli addons.
ember-try-test-suite-helper
A package for use in ember-try's test suite
ember-task-scheduler
An Ember CLI addon to schedule tasks to try to preserve 60 FPS rate on browsers.
An ember-cli addon to test against multiple npm dependencies, such as ember and ember-data.
npm install ember-try
Typescript
Module System
Min. Node Version
Node Version
NPM Version
JavaScript (98.67%)
HTML (1.2%)
Shell (0.08%)
Handlebars (0.05%)
Total Downloads
0
Last Day
0
Last Week
0
Last Month
0
Last Year
0
MIT License
181 Stars
870 Commits
59 Forks
10 Watchers
25 Branches
49 Contributors
Updated on Mar 07, 2025
Latest Version
4.0.0
Package Id
ember-try@4.0.0
Unpacked Size
100.73 kB
Size
23.33 kB
File Count
29
NPM Version
10.8.2
Node Version
18.20.7
Published on
Mar 07, 2025
Cumulative downloads
Total Downloads
Last Day
0%
NaN
Compared to previous day
Last Week
0%
NaN
Compared to previous week
Last Month
0%
NaN
Compared to previous month
Last Year
0%
NaN
Compared to previous year
An ember-cli addon to test against multiple dependencies, such as ember
and ember-data
.
ember install ember-try
This addon provides a few commands:
ember try:each
This command will run ember test
or the configured command with each scenario's specified in the config and exit appropriately.
This command is especially useful to use on CI to test against multiple ember
versions.
In order to use an alternate config path or to group various scenarios together in a single try:each
run, you can use
the --config-path
option.
ember try:each --config-path="config/legacy-scenarios.js"
If you need to know the scenario that is being run (i.e. to customize a test output file name) you can use the EMBER_TRY_CURRENT_SCENARIO
environment variable.
ember try:one <scenario> (...options) --- <command (Default: ember test)>
This command will run any ember-cli
command with the specified scenario. The command will default to ember test
, if no command is specified on the command-line or in configuration.
For example:
ember try:one ember-beta --- ember test --reporter xunit
or
ember try:one ember-beta --- ember serve
When running in a CI environment where changes are discarded you can skip resetting your environment back to its original state by specifying --skip-cleanup=true as an option to ember try. Warning: If you use this option and, without cleaning up, build and deploy as the result of a passing test suite, it will build with the last set of dependencies ember try was run with.
ember try:one ember-beta --skip-cleanup=true --- ember test
In order to use an alternate config path or to group various scenarios, you can use the --config-path
option.
ember try:one ember-beta --config-path="config/legacy-scenarios.js"
ember try:reset
This command restores all original files, and installs the original node modules again. For use if any of the other commands fail to clean up after (they run this by default on completion) or after running with ‘—skip-cleanup’.
ember try:ember <semver-string>
Runs ember test
or the command in config for each version of Ember that is possible under the semver string given. Configuration follows the rules given under the versionCompatibility
heading below.
ember try:config
Displays the configuration that will be used. Also takes an optional --config-path
.
If you're using ember-try
with an Ember addon, there is a short cut to test many Ember versions. In your package.json
under the ember-addon
key, add the following:
1 "ember-addon": { 2 "versionCompatibility": { 3 "ember": ">2.18.0 < 4.0.0" 4 } 5 }
The value for "ember" can be any valid semver statement.
This will autogenerate scenarios for each version of Ember that matches the statement. It will also include scenarios for beta
and canary
channels of Ember that will be allowed to fail.
These scenarios will ONLY be used if scenarios
is NOT a key in the configuration file being used.
If useVersionCompatibility
is set to true
in the config file, the autogenerated scenarios will deep merge with any scenarios in the config file. For example, you could override just the allowedToFail
property of the ember-beta
scenario.
To keep this from getting out of hand, ember-try
will limit the versions of Ember used to the lasted point release per minor version. For example, ">1.11.0 <=2.0.0", would (as of writing) run with versions ['1.11.4', '1.12.2', '1.13.13', '2.0.0'].
Configuration will be read from a file in your ember app in config/ember-try.js
. Here are the possible options:
1const getChannelURL = require('ember-source-channel-url'); 2 3module.exports = async function() { 4 return { 5 /* 6 `command` - a single command that, if set, will be the default command used by `ember-try`. 7 P.S. The command doesn't need to be an `ember <something>` command, they can be anything. 8 Keep in mind that this config file is JavaScript, so you can code in here to determine the command. 9 */ 10 command: 'ember test --reporter xunit', 11 /* 12 `npmOptions` - options to be passed to `npm`. 13 */ 14 npmOptions: ['--loglevel=silent'], 15 /* 16 If set to true, the `versionCompatibility` key under `ember-addon` in `package.json` will be used to 17 automatically generate scenarios that will deep merge with any in this configuration file. 18 */ 19 useVersionCompatibility: true, 20 /* 21 The package manager to use for all scenarios. By default, lockfiles will be ignored when installing dependencies. 22 At cleanup, all dependencies will be restored to their prior state. 23 */ 24 packageManager: 'npm' | 'pnpm' | 'yarn', 25 26 /* 27 buildManagerOptions allows you to opt-out of the default options such as `--ignore-engines --no-lockfile`. 28 The buildManagerOptions function is aware of each scenario so you can customize your options. 29 */ 30 buildManagerOptions(scenario) { 31 return ['--ignore-engines']; 32 } 33 34 scenarios: [ 35 { 36 name: 'Ember 2.11.0', 37 /* 38 `env` can be set per scenario, with environment variables to set for the command being run. 39 This will be merged with process.env 40 */ 41 env: { 42 ENABLE_NEW_DASHBOARD: true 43 }, 44 npm: { 45 devDependencies: { 46 'ember-source': '2.11.0' 47 }, 48 /* 49 You can optionally define npm or pnpm overrides to enforce a specific dependency version 50 to be installed. This is useful if other libraries you depend on include different 51 versions of a package. This does nothing if `packageManager` is `yarn`; 52 */ 53 overrides: { 54 'lodash': '5.0.0' 55 } 56 /* 57 When `packageManager` is `yarn`, you can optionally define yarn resolutions to enforce a 58 specific dependency version to be installed. This is useful if other libraries 59 you depend on include different versions of a package. 60 */ 61 resolutions: { 62 'lodash': '5.0.0' 63 } 64 /* 65 In order to easily test multiple editions ember-try merges any `ember` property specified 66 into the applications `package.json`. Values specified in the ember-try configuration will 67 override values that pre-existed in the original `package.json`. 68 */ 69 ember: { 70 'edition': 'octane' 71 } 72 } 73 }, 74 { 75 name: 'Ember canary with Ember-Data 2.3.0', 76 /* 77 `allowedToFail` - If true, if this scenario fails it will not fail the entire try command. 78 */ 79 allowedToFail: true, 80 npm: { 81 devDependencies: { 82 'ember-data': '2.3.0', 83 84 'ember-source': await getChannelURL('canary') 85 86 // you can remove any package by marking `null` 87 'some-optional-package': null 88 } 89 }, 90 }, 91 { 92 name: 'ember-beta', 93 npm: { 94 devDependencies: { 95 'ember-source': await getChannelURL('beta') 96 } 97 } 98 }, 99 ] 100 }; 101};
Scenarios are sets of dependencies. They can be specified exactly as in the package.json
The name
can be used to try just one scenario using the ember try:one
command.
If you include packageManager: 'yarn'
in your ember-try
config, all npm scenarios will use yarn
for install with the --no-lockfile
option. At cleanup, your dependencies will be restored to their prior state.
If you include packageManager: 'pnpm'
in your ember-try
config, all npm scenarios will use pnpm
for install with the --no-lockfile
options. At cleanup, your dependencies will be restored to their prior state.
⚠ pnpm versions from 8.0.0 to 8.6.x have the default value of resolution-mode setting changed to
lowest-direct
. This violatesember-try
expectations asresolution-mode
is expected to behighest
, like innpm
andpnpm
versions < 8.0.0 and >= 8.7.0.If you run into this issue, we recommend to upgrade pnpm to latest version. If you are unable to upgrade, you can set
resolution-mode = highest
in the.npmrc
file.
Lockfiles are ignored by ember-try
. (yarn
will run with --no-lockfile
and npm
will be run with --no-package-lock
and pnpm
will be run with --no-lockfile
).
When testing various scenarios, it's important to "float" dependencies so that the scenarios are run with the latest satisfying versions of dependencies a user of the project would get.
If you include useWorkspaces: true
in your ember-try
config, ember-try
will apply the diff to each individual workspace specified
in package.json
, allowing you to try scenarios in monorepo style repositories. See
Yarn's documentation of workspaces for more details.
See an example of using ember-try
for CI here, and the resulting build output.
npm link
and npm link ember-try
, otherwise any ember try
commands you run will use the version of ember-try included by ember-cli itself.No vulnerabilities found.
Reason
no dangerous workflow patterns detected
Reason
no binaries found in the repo
Reason
license file detected
Details
Reason
packaging workflow detected
Details
Reason
Found 12/13 approved changesets -- score normalized to 9
Reason
0 commit(s) and 1 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
security policy file not detected
Details
Reason
SAST tool is not run on all commits -- score normalized to 0
Details
Reason
45 existing vulnerabilities detected
Details
Score
Last Scanned on 2025-07-07
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