Gathering detailed insights and metrics for ember-auto-import
Gathering detailed insights and metrics for ember-auto-import
Gathering detailed insights and metrics for ember-auto-import
Gathering detailed insights and metrics for ember-auto-import
ember-auto-import-typescript
Enable `ember-auto-import` to import `.ts` files
ember-auto-import-chunks-json-generator
Ember.js addon to generate chunks.json file, based on ember-auto-import code splitting logic.
ember-load-initializers
A tiny add-on to autoload your initializer files in ember-cli.
ember-qunit
QUnit helpers for testing Ember.js applications
npm install ember-auto-import
59.1
Supply Chain
59.1
Quality
85.8
Maintenance
100
Vulnerability
95.9
License
v2.10.0-ember-auto-import
Published on 05 Nov 2024
v2.9.0-ember-auto-import
Published on 30 Oct 2024
v2.8.1-ember-auto-import
Published on 20 Sept 2024
v2.8.0-ember-auto-import
Published on 16 Sept 2024
v2.7.4-ember-auto-import
Published on 25 Jun 2024
v2.7.3-ember-auto-import
Published on 27 May 2024
Module System
Min. Node Version
Typescript Support
Node Version
NPM Version
360 Stars
1,049 Commits
109 Forks
17 Watching
34 Branches
51 Contributors
Updated on 26 Nov 2024
TypeScript (94.38%)
JavaScript (4.05%)
HTML (1.09%)
Shell (0.42%)
Handlebars (0.05%)
Cumulative downloads
Total Downloads
Last day
-16.6%
38,186
Compared to previous day
Last week
-10.9%
209,451
Compared to previous week
Last month
23.6%
993,319
Compared to previous month
Last year
-2.1%
13,422,883
Compared to previous year
36
30
Just import
from NPM, with zero configuration.
npm install --save-dev ember-auto-import webpack
If you're upgrading from 1.x to 2.x see the upgrade guide.
Add whatever dependency you want to your project using NPM or yarn like:
npm install --save-dev lodash-es
or
yarn add --dev lodash-es
Then just import it from your Ember app code:
1import { capitalize } from 'lodash-es';
There is no step two. Works from both app code and test code.
In addition to static top-level import
statements, you can use dynamic import()
to lazily load your dependencies. This can be great for reducing your initial bundle size.
Dynamic import is currently a Stage 3 ECMA feature, so to use it there are a few extra setup steps:
npm install --save-dev babel-eslint
In your .eslintrc.js
file, add
parser: 'babel-eslint'
In your ember-cli-build.js
file, enable the babel plugin provided by ember-auto-import:
1let app = new EmberApp(defaults, {
2 babel: {
3 plugins: [require.resolve('ember-auto-import/babel-plugin')],
4 },
5});
Once you're setup, you can use dynamic import()
and it will result in loading that particular dependency (and all its recursive dependencies) via a separate Javascript file at runtime. Here's an example of using dynamic import from within a Route
, so that the extra library needed for the route is loaded at the same time the data is loaded:
1export default Route.extend({ 2 model({ id }) { 3 return Promise.all([ 4 fetch(`/data-for-chart/${id}`).then(response => response.json()), 5 import('highcharts').then(module => module.default), 6 ]).then(([dataPoints, highcharts]) => { 7 return { dataPoints, highcharts }; 8 }); 9 }, 10});
If you're using custom deployment code, make sure it will include all the Javascript files in dist/assets
, not just the default app.js
and vendor.js
.
ember-auto-import
was originally designed to allow Ember apps to import from npm packages easily, and would have no influence on your app's files (i.e. files that exist in your app
folder). This meant that every time you had an import like import someBigLib from 'my-app-name/lib/massive'
there was no way for you to:
my-app-name/lib/massive
my-app-name/lib/massive
in such a way that it wouldn't increase the size of your asset.Fortunatly there is a way to configure ember-auto-import to work on certain parts of your app using the allowAppImports
configuration option. If you set the option to:
1let app = new EmberApp(defaults, {
2 autoImport: {
3 allowAppImports: [ 'lib/*' ],
4 }
5});
Then the my-app-name/lib/massive
file (and all other files in lib) would now be handled by ember-auto-import. This would then allow you to dynamically import('my-app-name/lib/massive')
which means that you can dynamically load parts of your app on demand without first splitting them into an addon or an npm package.
While most NPM packages authored in CommonJS or ES Modules will Just Work, for others you may need to give ember-auto-import a hint about what to do.
You can set options like this in your ember-cli-build.js:
1// In your ember-cli-build.js file
2let app = new EmberApp(defaults, {
3 autoImport: {
4 alias: {
5 // when the app tries to import from "plotly.js", use
6 // the real package "plotly.js-basic-dist" instead.
7 'plotly.js': 'plotly.js-basic-dist',
8
9 // you can also use aliases to pick a different entrypoint
10 // within the same package. This can come up when the default
11 // entrypoint only works in Node, but there is also a browser
12 // build available (and the author didn't provide a "browser"
13 // field in package.json that would let us detect it
14 // automatically).
15 handlebars: 'handlebars/dist/handlebars',
16
17 // We do a prefix match by default, so the above would also
18 // convert "handlebars/foo" to "handlebars/dist/handlesbars/foo".
19 // If instad you want an exact match only, you can use a trailing "$".
20 // For example, this will rewrite "some-package/alpha" to "customized"
21 // but leave "some-package/beta" alone.
22 'some-package/alpha$': 'customized',
23 },
24 allowAppImports: [
25 // minimatch patterns for app files that you want to be handled by ember-auto-import
26 ],
27 exclude: ['some-package'],
28 skipBabel: [
29 {
30 // when an already-babel-transpiled package like "mapbox-gl" is
31 // not skipped, it can produce errors in the production mode
32 // due to double transpilation
33 package: 'mapbox-gl',
34 semverRange: '*',
35 },
36 ],
37 watchDependencies: [
38 // trigger rebuilds if "some-lib" changes during development
39 'some-lib',
40 // trigger rebuilds if "some-lib"'s inner dependency "other-lib" changes
41 ['some-lib', 'other-lib'],
42 ],
43 webpack: {
44 // extra webpack configuration goes here
45 },
46 },
47});
Supported Options
alias
: object, Map from imported names to substitute names that will be imported instead. This is a prefix match by default. To opt out of prefix-matching and only match exactly, add a $
suffix to the pattern.allowAppImports
: list of strings, defaults to []. Files in your app folder that match these minimatch patterns will be handled by ember-auto-import (and thus Webpack) and no longer be part of the regular ember-cli pipeline.exclude
: list of strings, defaults to []. Packages in this list will be ignored by ember-auto-import. Can be helpful if the package is already included another way (like a shim from some other Ember addon).forbidEval
: boolean, defaults to false. We use eval
in development by default (because that is the fastest way to provide sourcemaps). If you need to comply with a strict Content Security Policy (CSP), you can set forbidEval: true
. You will still get sourcemaps, they will just use a slower implementation.insertScriptsAt
: string, defaults to undefined. Optionally allows you to take manual control over where ember-auto-import's generated <script>
tags will be inserted into your HTML and what attributes they will have. See "Customizing HTML Insertion" below.insertStylesAt
: string, defaults to undefined. Optionally allows you to take manual control over where ember-auto-import's generated <link rel="stylesheet">
tags (if any) will be inserted into your HTML and what attributes they will have. See "Customizing HTML Insertion" below.publicAssetURL
: the public URL to your /assets
directory on the web. Many apps won't need to set this because we try to detect it automatically, but you will need to set this explicitly if you're deploying your assets to a different origin than your app (for example, on a CDN) or if you are using <script defer>
(which causes scripts to be unable to guess what origin they loaded from).skipBabel
: list of objects, defaults to []. The specified packages will be skipped from babel transpilation.watchDependencies
: list of strings or string arrays, defaults to []. Tells ember-auto-import that you'd like to trigger a rebuild if one of these auto-imported dependencies changes. Pass a package name that refers to one of your own dependencies, or pass an array of package names to address a deeper dependency.webpack
: object, An object that will get merged into the configuration we pass to webpack. This lets you work around quirks in underlying libraries and otherwise customize the way Webpack will assemble your dependencies.Using ember-auto-import inside an addon is almost exactly the same as inside an app.
To add ember-auto-import to your addon:
add ember-auto-import to your dependencies
, not your devDependencies
, so it will be present when your addon is used by apps
add webpack to your devDependencies
(to support your test suite) but not your dependencies
(the app's version will be used)
document for your users that their app must depend on ember-auto-import >= 2 in order to use your addon
configure ember-auto-import (if needed) in your index.js
file (not your ember-cli-build.js
file), like this:
1// In your addon's index.js file 2module.exports = { 3 name: 'sample-addon', 4 options: { 5 autoImport: { 6 exclude: ['some-package'], 7 }, 8 }, 9};
if your addon uses Dynamic Import, it is required that you
register the babel plugin in your index.js
instead of ember-cli-build.js
:
1// index.js 2module.exports = { 3 options: { 4 babel: { 5 plugins: [require.resolve('ember-auto-import/babel-plugin')], 6 }, 7 }, 8};
devDependencies
of your addon into addon code (because that would fail in a consuming application). You can import devDependencies
into your test suite & dummy app.app
folder. This is because the files inside app
are conceptually not part of your addon's own package namespace at all, so they don't get access to your addon's dependencies. Do all your auto-importing from the addon
folder, and reexport in app
as needed.autoImport.webpack
option to add things to the webpack config, this makes them less likely to be broadly compatible with apps using different webpack versions. If you need to rely on a specific webpack feature, you should document which versions of webpack you support.ember-auto-import uses webpack to generate one or more chunk files containing all your auto-imported dependencies, and then ember-auto-import inserts <script>
tags to your HTML to make sure those chunks are included into your app (and tests, as appropriate). By default, the "app" webpack chunk(s) will be inserted after Ember's traditional "vendor.js" and the "tests" webpack chunk(s) will be inserted after "test-support.js".
If you need more control over the HTML insertion, you can use the insertScriptsAt
option (or the insertStylesAt
option, which is exactly analogous but for standalone CSS instead of JS). To customize HTML insertion:
Set insertScriptsAt
to a custom element name. You get to pick the name so that it can't collide with any existing custom elements in your site, but a good default choice is "auto-import-script":
1let app = new EmberApp(defaults, {
2 autoImport: {
3 insertScriptsAt: 'auto-import-script',
4 },
5});
In your index.html
and tests/index.html
, use the custom element to designate exactly where you want the "app" and "tests" entrypoints to be inserted:
1 <!-- in index.html --> 2 <body> 3 {{content-for "body"}} 4 <script src="{{rootURL}}assets/vendor.js"></script> 5+ <auto-import-script entrypoint="app"></auto-import-script> 6 <script src="{{rootURL}}assets/your-app.js"></script> 7 {{content-for "body-footer"}} 8 </body>
1 <!-- in tests/index.html --> 2 <body> 3 {{content-for "body"}} 4 {{content-for "test-body"}} 5 6 <div id="qunit"></div> 7 <div id="qunit-fixture"> 8 <div id="ember-testing-container"> 9 <div id="ember-testing"></div> 10 </div> 11 </div> 12 13 <script src="/testem.js" integrity=""></script> 14 <script src="{{rootURL}}assets/vendor.js"></script> 15+ <auto-import-script entrypoint="app"></auto-import-script> 16 <script src="{{rootURL}}assets/test-support.js"></script> 17+ <auto-import-script entrypoint="tests"></auto-import-script> 18 <script src="{{rootURL}}assets/your-app.js"></script> 19 <script src="{{rootURL}}assets/tests.js"></script> 20 21 {{content-for "body-footer"}} 22 {{content-for "test-body-footer"}} 23 </body>
Any attributes other than entrypoint
will be copied onto the resulting <script>
tags inserted by ember-auto-import. For example, if you want <script defer></script>
you can say:
1<auto-import-script defer entrypoint="app"> </auto-import-script>
And this will result in output like:
1<script defer src="/assets/chunk-12341234.js"></script>
Once you enable insertScriptsAt
you must designate places for the "app" and "tests" entrypoints if you want ember-auto-import to work correctly. You may also optionally designate additional entrypoints and manually add them to the webpack config. For example, you might want to build a polyfills bundle that needs to run before vendor.js
on pre-ES-module browsers:
1// ember-cli-build.js
2let app = new EmberApp(defaults, {
3 autoImport: {
4 insertScriptsAt: 'auto-import-script',
5 webpack: {
6 entry: {
7 polyfills: './lib/polyfills.js',
8 },
9 },
10 },
11});
12
13// lib/polyfills.js
14import 'core-js/stable';
15import 'intl';
1<!-- index.html --> 2<auto-import-script nomodule entrypoint="polyfills"></auto-import-script> 3<script src="{{rootURL}}assets/vendor.js"></script> 4<auto-import-script entrypoint="app"></auto-import-script> 5<script src="{{rootURL}}assets/your-app.js"></script>
ember-auto-import works with Fastboot to support server-side rendering.
When using Fastboot, you may need to add your Node version to config/targets.js
in order to only use Javascript features that work in that Node version. When you do this, it may prevent webpack from being able to infer that it should still be doing a build that targets the web. This may result in an error message like:
For the selected environment is no default script chunk format available:
JSONP Array push can be chosen when 'document' or 'importScripts' is available.
CommonJs exports can be chosen when 'require' or node builtins are available.
Make sure that your 'browserslist' includes only platforms that support these features or select an appropriate 'target' to allow selecting a chunk format by default. Alternatively specify the 'output.chunkFormat' directly.
You can fix this by setting the target to web explicitly:
1// ember-cli-build.js
2let app = new EmberApp(defaults, {
3 autoImport: {
4 webpack: {
5 target: 'web',
6 },
7 },
8});
global is undefined
or can't find module "path"
or can't find module "fs"
You're trying to use a library that is written to work in NodeJS and not in the browser. You can choose to polyfill the Node feature you need by passing settings to webpack. For example:
let app = new EmberApp(defaults, {
autoImport: {
webpack: {
node: {
global: true,
fs: 'empty'
}
}
}
See webpack's docs on Node polyfills.
See forbidEval
above.
Ember apps typically get jQuery from the ember-source
or @ember/jquery
packages. Neither of these is the real jquery
NPM package, so ember-auto-import cannot "see" it statically at build time. You will need to give webpack a hint to treat jQuery as external:
1// In your ember-cli-build.js file
2let app = new EmberApp(defaults, {
3 autoImport: {
4 webpack: {
5 externals: { jquery: 'jQuery' },
6 },
7 },
8});
Also, some jQuery plugins like masonry and flickity have required manual steps to connect them to jQuery.
ember-auto-import
version and now things don't import. What changed?As of version 1.4.0
, by default, ember-auto-import
does not include webpack's automatic polyfills for certain Node packages.
Some signs that your app was depending on these polyfills by accident are things like "global is not defined," "can't resolve path," or "default is not a function."
You can opt-in to Webpack's polyfills, or install your own.
See this issue for an example.
Uncaught ReferenceError: a is not defined
251 with an already babel transpiled addon, e.g: mapbox-gl
We should skip that specific addon from the ember-auto-import's babel transpilation as:
1// In your app's ember-cli-build.js file or check the `Usage from Addons` section for relevant usage of the following in addons 2let app = new EmberApp(defaults, { 3 autoImport: { 4 skipBabel: [ 5 { 6 package: 'mapbox-gl', 7 semverRange: '*', 8 }, 9 ], 10 }, 11});
Some modules, often times polyfills, don't provide values meant for direct import. Instead, the module is meant to provide certain side affects, such as mutating global variables.
To import a module for side affects only, you can simply import the module directly.
Any side affects the module provides will take affect.
Example: the eventsource
package provides a ready to use eventsource-polyfill.js module.
This can be imported like:
1// In any js file, likely the file you need to access the polyfill, purely for organization. 2 3// Importing the polyfill adds a new global object EventSourcePolyfill. 4import 'eventsource/example/eventsource-polyfill.js';
Set the environment variable DEBUG="ember-auto-import:*"
to see debug logging during the build.
To see Webpack's console output, set the environment variable AUTO_IMPORT_VERBOSE=true
.
Takes inspiration and some code from ember-browserify and ember-cli-cjs-transform. This package is basically what you get when you combine the ideas from those two addons.
This project is licensed under the MIT License.
No vulnerabilities found.
No security vulnerabilities found.