Gathering detailed insights and metrics for ember-cli-babel
Gathering detailed insights and metrics for ember-cli-babel
Gathering detailed insights and metrics for ember-cli-babel
Gathering detailed insights and metrics for ember-cli-babel
ember-cli-babel-plugin-helpers
Utilities for managing installed Babel plugins in an Ember app or addon
ember-cli-typescript
Allow Ember apps to use TypeScript files.
babel-plugin-ember-modules-api-polyfill
Polyfill for Ember JS API.
babel-plugin-ember-template-compilation
Babel implementation of Ember's low-level template-compilation API
npm install ember-cli-babel
Module System
Unable to determine the module system for this package.
Min. Node Version
Typescript Support
Node Version
NPM Version
153 Stars
980 Commits
120 Forks
11 Watching
21 Branches
75 Contributors
Updated on 19 Dec 2023
JavaScript (98.27%)
HTML (1.35%)
Handlebars (0.39%)
Cumulative downloads
Total Downloads
Last day
-13.3%
126,342
Compared to previous day
Last week
-7.6%
638,672
Compared to previous week
Last month
17.4%
2,867,925
Compared to previous month
Last year
52.6%
36,145,530
Compared to previous year
27
1
37
This Ember-CLI plugin uses Babel and @babel/preset-env to allow you to use latest Javascript in your Ember CLI project.
ember install ember-cli-babel
This plugin should work without any configuration after installing. By default
it will take every .js
file in your project and run it through the Babel
transpiler to convert your ES6 code to code supported by your target browsers
(as specified in config/targets.js
in ember-cli >= 2.13). Running non-ES6
code through the transpiler shouldn't change the code at all (likely just a
format change if it does).
If you need to customize the way that babel-preset-env
configures the plugins
that transform your code, you can do it by passing in any of the
babel/babel-preset-env options.
Note: .babelrc
files are ignored by default.
Example (configuring babel directly):
1// ember-cli-build.js
2
3let app = new EmberApp({
4 babel: {
5 // enable "loose" mode
6 loose: true,
7 // don't transpile generator functions
8 exclude: [
9 'transform-regenerator',
10 ],
11 plugins: [
12 require.resolve('transform-object-rest-spread')
13 ]
14 }
15});
Example (configuring ember-cli-babel itself):
1// ember-cli-build.js
2
3let app = new EmberApp({
4 'ember-cli-babel': {
5 compileModules: false
6 }
7});
There are a few different options that may be provided to ember-cli-babel.
These options are typically set in an apps ember-cli-build.js
file, or in an
addon or engine's index.js
.
1type BabelPlugin = string | [string, any] | [any, any]; 2 3interface EmberCLIBabelConfig { 4 /** 5 Configuration options for babel-preset-env. 6 See https://github.com/babel/babel-preset-env/tree/v1.6.1#options for details on these options. 7 */ 8 babel?: { 9 spec?: boolean; 10 loose?: boolean; 11 debug?: boolean; 12 include?: string[]; 13 exclude?: string[]; 14 useBuiltIns?: boolean; 15 sourceMaps?: boolean | "inline" | "both"; 16 plugins?: BabelPlugin[]; 17 }; 18 19 /** 20 Configuration options for ember-cli-babel itself. 21 */ 22 'ember-cli-babel'?: { 23 includeExternalHelpers?: boolean; 24 compileModules?: boolean; 25 disableDebugTooling?: boolean; 26 disablePresetEnv?: boolean; 27 disableEmberModulesAPIPolyfill?: boolean; 28 disableEmberDataPackagesPolyfill?: boolean; 29 disableDecoratorTransforms?: boolean; 30 enableTypeScriptTransform?: boolean; 31 extensions?: string[]; 32 }; 33}
The exact location you specify these options varies depending on the type of
project you're working on. As a concrete example, to add
babel-plugin-transform-object-rest-spread
so that your project can use object
rest/spread syntax, you would do something like this in an app:
1// ember-cli-build.js
2let app = new EmberApp(defaults, {
3 babel: {
4 plugins: [require.resolve('transform-object-rest-spread')]
5 }
6});
In an engine:
1// index.js 2module.exports = EngineAddon.extend({ 3 babel: { 4 plugins: [require.resolve('transform-object-rest-spread')] 5 } 6});
In an addon:
1// index.js 2module.exports = { 3 options: { 4 babel: { 5 plugins: [require.resolve('transform-object-rest-spread')] 6 } 7 } 8};
Babel often includes helper functions to handle some of the more complex logic in codemods. These functions are inlined by default, so they are duplicated in every file that they are used in, which adds some extra weight to final builds.
Enabling includeExternalHelpers
will cause Babel to import these helpers from
a shared module, reducing app size overall. This option is available only to
the root application, because it is a global configuration value due to the fact
that there can only be one version of helpers included.
Note that there is currently no way to allow or ignore helpers, so all helpers will be included, even ones which are not used. If your app is small, this could add to overall build size, so be sure to check.
ember-cli-babel
will attempt to include helpers if it believes that it will
lower your build size, using a number of heuristics. You can override this to
force inclusion or exclusion of helpers in your app by passing true
or false
to includeExternalHelpers
in your ember-cli-babel
options.
1// ember-cli-build.js
2
3let app = new EmberApp(defaults, {
4 'ember-cli-babel': {
5 includeExternalHelpers: true
6 }
7});
Babel generated source maps will enable you to debug your original ES6 source code. This is disabled by default because it will slow down compilation times.
To enable it, pass sourceMaps: 'inline'
in your babel
options.
1// ember-cli-build.js
2
3let app = new EmberApp(defaults, {
4 babel: {
5 sourceMaps: 'inline'
6 }
7});
Older versions of Ember CLI (< 2.12
) use its own ES6 module transpiler.
Because of that, this plugin disables Babel module compilation by ignoring
that transform when running under affected ember-cli versions. If you find that
you want to use the Babel module transform instead of the Ember CLI one, you'll
have to explicitly set compileModules
to true
in your configuration. If
compileModules
is anything other than true
, this plugin will leave the
module syntax compilation up to Ember CLI.
If for some reason you need to disable this debug tooling, you can opt-out via configuration.
In an app that would look like:
1// ember-cli-build.js
2module.exports = function(defaults) {
3 let app = new EmberApp(defaults, {
4 'ember-cli-babel': {
5 disableDebugTooling: true
6 }
7 });
8
9 return app.toTree();
10}
Babel needs a transform plugin in order to transpile TypeScript. When you
install ember-cli-typescript >= 4.0
, this plugin is automatically enabled.
If you don't want to install ember-cli-typescript
, you can still enable
the TypeScript-Babel transform. You will need to set enableTypeScriptTransform
to true
in select file(s).
1/* ember-cli-build.js */
2
3const EmberApp = require('ember-cli/lib/broccoli/ember-app');
4
5module.exports = function (defaults) {
6 const app = new EmberApp(defaults, {
7 // Add options here
8 'ember-cli-babel': {
9 enableTypeScriptTransform: true,
10 },
11 });
12
13 return app.toTree();
14};
1/* ember-cli-build.js */
2
3const EmberAddon = require('ember-cli/lib/broccoli/ember-addon');
4
5module.exports = function (defaults) {
6 const app = new EmberAddon(defaults, {
7 // Add options here
8 'ember-cli-babel': {
9 enableTypeScriptTransform: true,
10 },
11 });
12
13 return app.toTree();
14};
1/* index.js */ 2 3module.exports = { 4 name: require('./package').name, 5 6 options: { 7 'ember-cli-babel': { 8 enableTypeScriptTransform: true, 9 }, 10 }, 11};
1/* ember-cli-build.js */
2
3const EmberAddon = require('ember-cli/lib/broccoli/ember-addon');
4
5module.exports = function (defaults) {
6 const app = new EmberAddon(defaults, {
7 // Add options here
8 'ember-cli-babel': {
9 enableTypeScriptTransform: true,
10 },
11 });
12
13 return app.toTree();
14};
1/* index.js */ 2 3const { buildEngine } = require('ember-engines/lib/engine-addon'); 4 5module.exports = buildEngine({ 6 name: require('./package').name, 7 8 'ember-cli-babel': { 9 enableTypeScriptTransform: true, 10 }, 11});
NOTE: Setting enableTypeScriptTransform
to true
does not enable
type-checking. For integrated type-checking, you will need
ember-cli-typescript
.
If you want to use the existing babel config from your project instead of the auto-generated one from this addon, then you would need to opt-in by passing the config useBabelConfig: true
as a child property of ember-cli-babel
in your ember-cli-build.js
file.
Note: If you are using this option, then you have to make sure that you are adding all of the required plugins required for Ember to transpile correctly.
Example usage:
1//ember-cli-build.js
2
3let app = new EmberAddon(defaults, {
4 "ember-cli-babel": {
5 useBabelConfig: true,
6 // ember-cli-babel related options
7 },
8});
1//babel.config.js 2 3const { buildEmberPlugins } = require("ember-cli-babel"); 4 5module.exports = function (api) { 6 api.cache(true); 7 8 return { 9 presets: [ 10 [ 11 require.resolve("@babel/preset-env"), 12 { 13 targets: require("./config/targets"), 14 }, 15 ], 16 ], 17 plugins: [ 18 // if you want external helpers 19 [ 20 require.resolve("@babel/plugin-transform-runtime"), 21 { 22 version: require("@babel/plugin-transform-runtime/package").version, 23 regenerator: false, 24 useESModules: true, 25 }, 26 ], 27 // this is where all the ember required plugins would reside 28 ...buildEmberPlugins(__dirname, { /*customOptions if you want to pass in */ }), 29 ], 30 }; 31};
Ember Plugins is a helper function that returns a list of plugins that are required for transpiling Ember correctly. You can import this helper function and add it to your existing babel.config
file.
The first argument is required which is the path to the root of your project (generally __dirname
).
Config options:
1{ 2 disableModuleResolution: boolean, // determines if you want the module resolution enabled 3 emberDataVersionRequiresPackagesPolyfill: boolean, // enable ember data's polyfill 4 shouldIgnoreJQuery: boolean, // ignore jQuery 5 shouldIgnoreEmberString: boolean, // ignore ember string 6 shouldIgnoreDecoratorAndClassPlugins: boolean, // disable decorator plugins 7 disableEmberModulesAPIPolyfill: boolean, // disable ember modules API polyfill 8}
V2 Addons do not use ember-cli-babel
and hence should remove ember-cli-babel
from their dependencies entirely.
You can read up on how each of the V1 features described below can be re-expressed within a V2 addon via the links below:
You can add custom plugins to be used during transpilation of the addon/
or
addon-test-support/
trees by ensuring that your addon's options.babel
is
properly populated (as mentioned above in the Options
section).
For addons which want additional customizations, they are able to interact with this addon directly.
1interface EmberCLIBabel {
2 /**
3 Used to generate the options that will ultimately be passed to babel itself.
4 */
5 buildBabelOptions(type: 'babel' | 'broccoli', config?: EmberCLIBabelConfig): Opaque;
6
7 /**
8 Supports easier transpilation of non-standard input paths (e.g. to transpile
9 a non-addon NPM dependency) while still leveraging the logic within
10 ember-cli-babel for transpiling (e.g. targets, preset-env config, etc).
11 */
12 transpileTree(inputTree: BroccoliTree, config?: EmberCLIBabelConfig): BroccoliTree;
13
14 /**
15 Used to determine if a given plugin is required by the current target configuration.
16 Does not take `includes` / `excludes` into account.
17
18 See https://github.com/babel/babel-preset-env/blob/master/data/plugins.json for the list
19 of known plugins.
20 */
21 isPluginRequired(pluginName: string): boolean;
22}
buildBabelOptions
usage1// find your babel addon (can use `this.findAddonByName('ember-cli-babel')` in ember-cli@2.14 and newer) 2let babelAddon = this.addons.find(addon => addon.name === 'ember-cli-babel'); 3 4// create the babel options to use elsewhere based on the config above 5let options = babelAddon.buildBabelOptions('babel', config) 6 7// now you can pass these options off to babel or broccoli-babel-transpiler 8require('babel-core').transform('something', options);
getSupportedExtensions
usage1// find your babel addon (can use `this.findAddonByName('ember-cli-babel')` in ember-cli@2.14 and newer) 2let babelAddon = this.addons.find(addon => addon.name === 'ember-cli-babel'); 3 4// create the babel options to use elsewhere based on the config above 5let extensions = babelAddon.getSupportedExtensions(config)
transpileTree
usage1// find your babel addon (can use `this.findAddonByName('ember-cli-babel')` in ember-cli@2.14 and newer) 2let babelAddon = this.addons.find(addon => addon.name === 'ember-cli-babel'); 3 4// invoke .transpileTree passing in the custom input tree 5let transpiledCustomTree = babelAddon.transpileTree(someCustomTree);
In order to allow apps and addons to easily provide good development mode ergonomics (assertions, deprecations, etc) but still perform well in production mode ember-cli-babel automatically manages stripping / removing certain debug statements. This concept was originally proposed in ember-cli/rfcs#50, but has been slightly modified during implementation (after researching what works well and what does not).
To add convienient deprecations and assertions, consumers (in either an app or an addon) can do the following:
1import { deprecate, assert } from '@ember/debug'; 2 3export default Ember.Component.extend({ 4 init() { 5 this._super(...arguments); 6 deprecate( 7 'Passing a string value or the `sauce` parameter is deprecated, please pass an instance of Sauce instead', 8 false, 9 { until: '1.0.0', id: 'some-addon-sauce' } 10 ); 11 assert('You must provide sauce for x-awesome.', this.sauce); 12 } 13})
In testing and development environments those statements will be executed (and assert or deprecate as appropriate), but in production builds they will be inert (and stripped during minification).
The following are named exports that are available from @ember/debug
:
function deprecate(message: string, predicate: boolean, options: any): void
- Results in calling Ember.deprecate
.function assert(message: string, predicate: boolean): void
- Results in calling Ember.assert
.function warn(message: string, predicate: boolean): void
- Results in calling Ember.warn
.In some cases you may have the need to do things in debug builds that isn't
related to asserts/deprecations/etc. For example, you may expose certain API's
for debugging only. You can do that via the DEBUG
environment flag:
1import { DEBUG } from '@glimmer/env'; 2 3const Component = Ember.Component.extend(); 4 5if (DEBUG) { 6 Component.reopen({ 7 specialMethodForDebugging() { 8 // do things ;) 9 } 10 }); 11}
In testing and development environments DEBUG
will be replaced by the boolean
literal true
, and in production builds it will be replaced by false
. When
ran through a minifier (with dead code elimination) the entire section will be
stripped.
Please note, that these general purpose environment related flags (e.g. DEBUG
as a boolean flag) are imported from @glimmer/env
not from an @ember
namespace.
By default, broccoli-babel-transpiler will attempt to spin up several sub-processes (~1 per available core), to achieve parallelization. (Once Node.js has built-in worker support, we plan to utilize it.) This yields significant Babel build time improvements.
Unfortunately, some Babel plugins may break this functionality. When this occurs, we gracefully fallback to the old serial strategy.
To have the build fail when failing to do parallel builds, opt-in is via:
1let app = new EmberAddon(defaults, {
2 'ember-cli-babel': {
3 throwUnlessParallelizable: true
4 }
5});
or via environment variable via
1THROW_UNLESS_PARALLELIZABLE=1 ember serve
The ember-cli-build
option is only specifying that your ember-cli-babel
is parallelizable, not that all of them are.
The environment variable works by instructing all ember-cli-babel
instances to put themselves in parallelize mode (or throw).
Note: Future versions will enable this flag by default.
Read more about broccoli parallel transpilation.
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 6/12 approved changesets -- score normalized to 5
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
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
22 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