Vite Tracking Branch

.local.dic

@@ -22,7 +22,7 @@ BelongsTo
 blockquote
 blogPost
 bookmarklet
-Browserlist
+Browserslist
 callouts
 camelize
 centric
@@ -52,6 +52,7 @@ debounce
 declaratively
 DefinitelyTyped
 deps
+dev
 draggable
 dropdown
 durations
@@ -62,6 +63,7 @@ els-addon-typed-templates
 ember-a11y
 ember-a11y-refocus
 ember-a11y-testing
+ember-cli
 ember-cli-cjs-transform
 ember-cli-deprecation-workflow
 ember-cli-document-title
@@ -130,6 +132,7 @@ linters
 lookups
 LSP
 Mapbox
+TomTom
 MDN
 metaprogramming
 misspelt
@@ -178,6 +181,8 @@ rerender
 rerendering
 rerenders
 RequestManager
+rollup
+Rollup
 routable
 RunDOC
 runnable
@@ -217,6 +222,7 @@ templating
 TextMate
 todo
 todos
+toolchain
 tooltip
 tooltips
 trackable
@@ -253,3 +259,6 @@ working-with-html-css-and-javascript
 yay
 ZEIT
 userQuestion
+vite
+Vite
+bundler

.remarkignore

@@ -5,36 +5,9 @@ MAINTAINERS.md
 # old major versions
 guides/v1*/**/*.md
 guides/v2*/**/*.md
-
-# current major version
-guides/v3.0.0/**/*.md
-guides/v3.1.0/**/*.md
-guides/v3.2.0/**/*.md
-guides/v3.3.0/**/*.md
-guides/v3.4.0/**/*.md
-guides/v3.5.0/**/*.md
-guides/v3.6.0/**/*.md
-guides/v3.7.0/**/*.md
-guides/v3.8.0/**/*.md
-guides/v3.9.0/**/*.md
-guides/v3.10.0/**/*.md
-guides/v3.11.0/**/*.md
-guides/v3.12.0/**/*.md
-guides/v3.13.0/**/*.md
-guides/v3.14.0/**/*.md
-guides/v3.15.0/**/*.md
-guides/v3.16.0/**/*.md
-guides/v3.17.0/**/*.md
-guides/v3.18.0/**/*.md
-guides/v3.19.0/**/*.md
-guides/v3.20.0/**/*.md
-guides/v3.21.0/**/*.md
-guides/v3.22.0/**/*.md
-guides/v3.23.0/**/*.md
-guides/v3.24.0/**/*.md
-guides/v3.25.0/**/*.md
-guides/v3.26.0/**/*.md
-guides/v3.27.0/**/*.md
+guides/v3*/**/*.md
+guides/v4*/**/*.md
+guides/v5*/**/*.md
 
 # redirect only files
 guides/release/working-with-javascript

guides/release/addons-and-dependencies/index.md

@@ -2,171 +2,30 @@ As you're developing your Ember app, you are likely to run into common scenarios
 Perhaps you want to use a CSS preprocessor to write your stylesheets, or you want to use a popular JS library, or maybe
 you want to import components written by a different department within your organization.
 
-Ember CLI provides a common format called [Ember Addons](#toc_addons) for distributing reusable libraries to solve some
+Ember provides a common format called [Ember Addons](#toc_addons) for distributing reusable libraries to solve some
 of these problems.  Additionally, you may want to make use of front-end dependencies like a CSS framework or a JavaScript
 datepicker that aren't specific to Ember apps.
 
 ## Addons
 
-Addons are JavaScript packages that integrate with Ember. For example, [`ember-cli-sass`](https://github.com/adopted-ember-addons/ember-cli-sass)
-is an addon that allows you to use SASS/SCSS in your applications. You can install it using the Ember CLI with the following command:
+Addons are JavaScript packages that integrate with Ember. For example, [`ember-concurrency`](https://github.com/machty/ember-concurrency) provides a concurrency primitive that you can use in your Ember app as well as a [Babel](https://babeljs.io/) plugin that makes it easier to use in an Ember application. You can install it just like any other npm package:
 
 ```bash
-ember install ember-cli-sass
+npm install --save-dev ember-cli-sass
 ```
 
-This will modify your `package.json` (and `package-lock.json` or `yarn.lock` or `pnpm-lock.yaml`), typically bringing in other dependencies. Some addons will also add
-additional files to your projects when relevant.
-
-There are many addons that cover all kinds of use cases. For more detail, as well as examples of what addons can do,
-we invite you to have a look at the [Ember CLI documentation](https://cli.emberjs.com/release/basic-use/using-addons/).
+And then follow any additional instructions in the README of the addon. Some addons (like `ember-concurrency`) will give instructions for extra steps that you might need like installing a Babel plugin so it's always worthwhile reading the installation documentation.
 
 The Ember community publishes and maintains many addons, and it can be difficult to know if one (or many!) exists that covers
 your needs. The website [Ember Observer](https://www.emberobserver.com/) keeps an up-to-date index of Ember Addons, sorted by
 categories, and rated according to objective metrics. If you are looking for an addon, we recommend that you start there!
 
 ## Regular npm packages
 
-While dependencies can be managed in several ways,
-it's worth noting that the process can be greatly simplified for new developers by using ember-auto-import,
-which offers zero config imports from npm packages. 
-It's built into new Ember apps by default and can be installed in older apps by using `ember install ember-auto-import`.
-For further usage instructions, please follow the [project README](https://github.com/ef4/ember-auto-import).
-
-## Other assets
-
-Third-party JavaScript not available as an addon or npm package should be placed in the `vendor/` folder in your project.
-
-Your own assets (such as `robots.txt`, `favicon`, custom fonts, etc) should be placed in the `public/` folder in your project.
-
-## Compiling Assets
-
-When you're using dependencies that are not included in an addon,
-you will have to instruct Ember CLI to include your assets in the build.
-This is done using the asset manifest file `ember-cli-build.js`.
-You should only try to import assets located in the `node_modules` and `vendor` folders.
-
-### Globals provided by JavaScript assets
-
-The globals provided by some assets (like `moment` in the below example) can be used in your application
-without the need to `import` them.
-Provide the asset path as the first and only argument.
-
-```javascript {data-filename=ember-cli-build.js}
-app.import('node_modules/moment/moment.js');
-```
-
-You will need to add `"moment"` to the `globals` section in `.eslintrc.js` to prevent ESLint errors
-about using an undefined variable.
-
-### Anonymous AMD JavaScript modules
-
-You can transform an anonymous AMD module to a named one by using the `amd` transformation.
-
-```javascript {data-filename=ember-cli-build.js}
-app.import('node_modules/moment/moment.js', {
-  using: [
-    { transformation: 'amd', as: 'moment' }
-  ]
-});
-```
-
-This transformation allows you to `import` moment in your app. (e.g. `import moment from 'moment';`)
-
-### CommonJS JavaScript modules
-
-[ember-cli-cjs-transform](https://github.com/rwjblue/ember-cli-cjs-transform) allows us to import CommonJS modules into
-our Ember app. It also does auto-rollup and some nice caching, so it should pull in all the deps that are pulled in
-with `require` for you automatically. It is not yet included with Ember CLI by default, so you will need to install it.
-
-```bash
-ember install ember-cli-cjs-transform
-```
-
-```javascript {data-filename=ember-cli-build.js}
-app.import('node_modules/showdown/dist/showdown.js', {
-  using: [
-    { transformation: 'cjs', as: 'showdown' }
-  ]
-});
-```
-
-You can now `import` them in your app. (e.g. `import showdown from 'showdown';`)
-
-### Environment-Specific Assets
+For newly generated Ember apps, the majority of the build is managed by [Vite](https://vite.dev/) which means that any npm packages or other assets can just be imported as you might expect in a modern build system or bundler.
 
-If you need to use different assets in different environments, specify an object as the first parameter.
-That object's key should be the environment name, and the value should be the asset to use in that environment.
+In previous versions of Ember (before we moved to using Vite) there were other concepts that you would need to know to include 3rd party packages or assets in your app. If you are working on an Ember app that hasn't yet been upgraded to Vite you should look at [previous versions of this guide](/v6.7.0/addons-and-dependencies/) to get more information about the legacy build system.
 
-```javascript {data-filename=ember-cli-build.js}
-app.import({
-  development: 'node_modules/moment/moment.js',
-  production:  'node_modules/moment/min/moment.min.js'
-});
-```
-
-If you need to import an asset in only one environment you can wrap `app.import` in an `if` statement.
-For assets needed during testing, you should also use the `{type: 'test'}` option to make sure they
-are available in test mode.
-
-```javascript {data-filename=ember-cli-build.js}
-if (app.env === 'development') {
-  // Only import when in development mode
-  app.import('vendor/ember-renderspeed/ember-renderspeed.js');
-}
-if (app.env === 'test') {
-  // Only import in test mode and place in test-support.js
-  app.import('node_modules/sinonjs/sinon.js', { type: 'test' });
-  app.import('node_modules/sinon-qunit/lib/sinon-qunit.js', { type: 'test' });
-}
-```
-
-### CSS
-
-Provide the asset path as the first argument:
-
-```javascript {data-filename=ember-cli-build.js}
-app.import('node_modules/foundation/css/foundation.css');
-```
-
-All style assets added this way will be concatenated and output as `/assets/vendor.css`.
-
-### Other Assets
-
-All assets located in the `public/` folder will be copied as is to the final output directory, `dist/`.
-
-For example, a `favicon` located at `public/images/favicon.ico` will be copied to `dist/images/favicon.ico`.
-
-All third-party assets, included either manually in `vendor/` or via a package manager like npm, must be added via `app.import()`.
-
-Third-party assets that are not added via `app.import()` will not be present in the final build.
-
-By default, `import`ed assets will be copied to `dist/` as they are, with the existing directory structure maintained.
-
-```javascript {data-filename=ember-cli-build.js}
-app.import('node_modules/font-awesome/fonts/fontawesome-webfont.ttf');
-```
-
-This example would create the font file in `dist/font-awesome/fonts/fontawesome-webfont.ttf`.
-
-You can also optionally tell `import()` to place the file at a different path.
-The following example will copy the file to `dist/assets/fontawesome-webfont.ttf`.
-
-```javascript {data-filename=ember-cli-build.js}
-app.import('node_modules/font-awesome/fonts/fontawesome-webfont.ttf', {
-  destDir: 'assets'
-});
-```
-
-If you need to load certain dependencies before others,
-you can set the `prepend` property equal to `true` on the second argument of `import()`.
-This will prepend the dependency to the vendor file instead of appending it, which is the default behavior.
-
-```javascript {data-filename=ember-cli-build.js}
-app.import('node_modules/es5-shim/es5-shim.js', {
-  type: 'vendor',
-  prepend: true
-});
-```
+To know more about how Vite can be configured, e.g. how it [handles static assets](https://vite.dev/guide/assets), you can consult their guides: [https://vite.dev/guide/](https://vite.dev/guide/)
 
 <!-- eof - needed for pages that end in a code block  -->

guides/release/build-tools/index.md

@@ -0,0 +1,17 @@
+Ember supports two different build environments:
+
+ - Our [Vite integration](./vite) works on all Ember versions back to 3.28. It became the default for newly-generated apps at Ember 6.8.
+ - The legacy [ember-cli based build](https://cli.emberjs.com/release/) is also still supported on all Ember versions.
+
+You can tell which one you're using based on the presence of `@embroider/vite` in your `package.json` file.
+
+Existing apps can use [Ember Vite Codemod](https://github.com/mainmatter/ember-vite-codemod) to switch from the ember-cli based build to the Vite based build.
+
+On Ember versions after 6.8, you can optionally choose to generate a new app using the older build environment via:
+
+```sh
+npx ember-cli@ new my-app-name -b @ember-tooling/classic-build-app-blueprint
+```
+
+
+

guides/release/build-tools/vite.md

@@ -0,0 +1,32 @@
+When you generate a new Ember app your default build system will be using Vite.
+
+> Vite is a blazing fast frontend build tool powering the next generation of web applications.
+
+You can read more about [Vite on their documentation](https://vite.dev/guide/) site. Ember's Vite implementation is [powered by Embroider](https://github.com/embroider-build/embroider), which acts as a Vite plugin that allows Vite to effectively build an Ember app.
+
+## Basic Usage
+
+For most developers the only interaction that they will have with the build system is running the `npm start`, or `npm run build` scripts defined in their `package.json`. If you have a look at your `package.json` scripts you will see that they are just deferring to `vite` (which by default runs `vite dev` and starts the Vite dev server) and `vite build` respectively.
+
+You can see more docs on these commands in the Vite documentation
+
+### Sensible defaults
+
+As Ember developers we expect reasonable defaults, because of that we have provided a default vite config for you that takes care of most of the Vite configuration you need as an Ember developer. For example, we automatically include your `tests/index.html` in the `build.rollupOptions.input` when you are building in `develoment` mode so that you can navigate to http://localhost:4200/tests/ 
+
+For most applications you will not need to override the config that we provide by default, instead you can just add to the config as you need. If you do need to change the defaults that we provide, you can just define the new configuration in your `vite.config.js` because anything you define there will take precedence over anything we provide.
+
+
+### Integrating 3rd party plugins
+
+Now that Ember uses Vite for its build system, you no longer need an Ember-specific plugin to augment your build. If you find a Vite or rollup plugin that you would like to use you can follow the installation instructions to add that to your `vite.config.js` without any Ember-specific instructions necessary.
+
+## Advanced Usage
+
+Most developers will not need to change the defaults that we provide, but in some rare cases it can be useful to know how to change the defaults.
+
+### Running Tests Against Production Code
+
+By default, we don't build your tests when you build for production. This is because, in most cases, people don't want their tests included in the bundle they ship to end-users. This means if you run `npm run build` in your app it will default to `--mode production` (because this is [the default for `vite build`](https://vite.dev/config/shared-options.html#mode)) and it will not include your tests in your build output.
+
+If you needed to run your tests against your production environment for any reason (maybe you have a vite/rollup plugin that you only run during your production build) then you can use the `FORCE_BUILD_TESTS=true` environment variable. This is just a convenience in the code that the default `ember()` plugin provides, you can always define your inputs in the `vite.config.js` which will take precedent over anything we're doing automatically for you in the `ember()` plugin.

guides/release/configuring-ember/build-targets.md

@@ -1,14 +1,39 @@
-Ember application builds are created by the Ember CLI build pipeline. Just as with your application code,
-Ember CLI ships with a sensible set of defaults to compile and bundle the assets that can be deployed
-to production. Under the hood, this is accomplished using a series of Broccoli plugins, each of which
-can be configured in the `ember-cli-build.js` file at the root of your project.
-
-Ember CLI uses [Babel.js](https://babeljs.io/) for the compile step in this process. If you've used Babel
-before, you know that it comes with a large set of options, including the ability to configure
-"targets"; i.e. the environments in which your application is expected to run.
-For example, if your application is embedded in an [Electron app](https://www.electronjs.org),
-you might only care about compiling for the latest Chromium build. Or if your app targets Enterprise
-users, you may need to compile your JavaScript to older syntax that runs in IE11.
-
-For any of these cases, you can configure `ember build` to do The Right Thing. You can read more about
-this in [the Ember CLI Guides](https://cli.emberjs.com/release/advanced-use/build-targets/)!
+By default, Ember apps are built with Vite. The toolchain uses Babel, esbuild, and Rollup so you can write current-generation JavaScript and TypeScript while still allowing your application to work with older browsers.
+
+Rather than always compiling everything down to legacy syntax, Ember determines what—if anything—needs to be transformed based on the browsers you target. With today’s defaults aimed at evergreen browsers, many features (ES modules, classes, arrow functions, async/await, etc.) ship largely as-is.
+
+Why does this matter? Over-transpiling to very old JavaScript increases bundle size, slows parsing, and in some cases can slow down the execution of your JavaScript code. As the Web platform has advanced and percentage of users on legacy browsers have decreased, Ember’s default targets avoid unnecessary transforms to keep apps smaller and faster.
+
+If you need to update the defaults for any reason (i.e. need to target a very legacy browser), you can set the targets for your app and the compiler applies only the minimal transforms and polyfills required for those browsers.
+
+If you open `config/targets.js`, you will find the following code:
+
+```javascript {data-filename=config/targets.js}
+"use strict";
+
+const browsers = [
+  "last 1 Chrome versions",
+  "last 1 Firefox versions",
+  "last 1 Safari versions",
+];
+
+module.exports = {
+  browsers,
+};
+```
+
+If you inspect your compiled code after running a build with `npm run build`, you'll see that many modern features (like arrow functions and async/await) preserved when your targets support them.
+
+This feature is backed by [Browserslist](https://github.com/ai/browserslist) and [Can I Use](https://caniuse.com/).
+These websites track usage stats of browsers, so you can use complex queries based on the user base of every browser.
+
+If you want to target all browsers with more than a 4% market share in Canada,
+you'd have the following options:
+
+```javascript {data-filename=config/targets.js}
+module.exports = {
+  browsers: ["> 4% in CA"],
+};
+```
+
+It is very important that you properly configure the targets of your app so you get the smallest and fastest code possible.

guides/release/configuring-ember/optional-features.md

@@ -7,15 +7,7 @@ To give the project a path forward when a breaking change is mandatory, we've re
 
 This addon does nothing by default, but provides a command-line interface to enable and disable breaking changes in Ember.
 
-## Installation
-
-To get started with optional features, you must install the addon:
-
-```bash
-ember install @ember/optional-features
-```
-
-This will make three new commands available to Ember CLI within your project, `feature:list`, `feature:enable`, and `feature:disable`.
+`@ember/optional-features` is installed by default when generating a new ember application.
 
 ## Listing features