From eddb1f5d20617b871f636c0b2cc0c018a7456ec7 Mon Sep 17 00:00:00 2001 From: TWIOS Dev Date: Sun, 7 Jul 2024 23:02:17 +0000 Subject: [PATCH 1/6] twios-2024-07-07 --- config/this-week-in-open-source.config.json | 2 +- src/twios/2024-07-07.md | 100 ++++++++++++++++++++ 2 files changed, 101 insertions(+), 1 deletion(-) create mode 100644 src/twios/2024-07-07.md diff --git a/config/this-week-in-open-source.config.json b/config/this-week-in-open-source.config.json index f8385ae390..b2ed45babb 100644 --- a/config/this-week-in-open-source.config.json +++ b/config/this-week-in-open-source.config.json @@ -556,6 +556,6 @@ ], "exclude_closed_not_merged": true, "output_path": "src/twios/", - "last_date": "2024-06-16..2024-06-23", + "last_date": "", "query_type": "Merged" } \ No newline at end of file diff --git a/src/twios/2024-07-07.md b/src/twios/2024-07-07.md new file mode 100644 index 0000000000..6c0a3c4817 --- /dev/null +++ b/src/twios/2024-07-07.md @@ -0,0 +1,100 @@ +## Rust + +- [marcoow/pacesetter] [#72](https://github.com/marcoow/pacesetter/pull/72) Add + READMEs to blueprint ([@marcoow]) +- [marcoow/pacesetter] [#71](https://github.com/marcoow/pacesetter/pull/71) + don't create db_test macro for minimal project type ([@marcoow]) +- [marcoow/pacesetter] [#70](https://github.com/marcoow/pacesetter/pull/70) run + CI daily ([@marcoow]) +- [marcoow/pacesetter] [#48](https://github.com/marcoow/pacesetter/pull/48) add + README and LICENSE ([@marcoow]) + +## Svelte + +- [mainmatter/sheepdog] [#114](https://github.com/mainmatter/sheepdog/pull/114) + Add timeout utility function ([@nickschot]) +- [sveltejs/svelte] [#12290](https://github.com/sveltejs/svelte/pull/12290) fix: + correctly teardown `bind:this` with `$state.frozen` ([@paoloricciuti]) + +## Embroider + +- [embroider-build/embroider] + [#2017](https://github.com/embroider-build/embroider/pull/2017) update vite to + have a minimum version of 5.2 ([@mansona]) +- [embroider-build/embroider] + [#2015](https://github.com/embroider-build/embroider/pull/2015) update github + actions ([@mansona]) +- [embroider-build/embroider] + [#1931](https://github.com/embroider-build/embroider/pull/1931) update + scenario-tester ([@mansona]) +- [embroider-build/embroider] + [#1930](https://github.com/embroider-build/embroider/pull/1930) create a smoke + test for the widest possible matrix ([@mansona]) +- [embroider-build/embroider] + [#2012](https://github.com/embroider-build/embroider/pull/2012) Empty packages + as valid v2 addons ([@BlueCutOfficial]) + +## Ember + +- [ember-learn/ember-api-docs] + [#914](https://github.com/ember-learn/ember-api-docs/pull/914) fix + require-expect lint ([@mansona]) +- [ember-learn/ember-api-docs-data] + [#30](https://github.com/ember-learn/ember-api-docs-data/pull/30) Fix names in + source s3 files ([@mansona]) +- [mainmatter/ember-cookies] + [#946](https://github.com/mainmatter/ember-cookies/pull/946) chore(ci): + strategy.fail-fast=false ([@BobrImperator]) +- [mainmatter/ember-cookies] + [#945](https://github.com/mainmatter/ember-cookies/pull/945) chore: ci fixes + ([@BobrImperator]) +- [mainmatter/ember-cookies] + [#944](https://github.com/mainmatter/ember-cookies/pull/944) chore(deps): + migrate eslint to new configuration syntax ([@BobrImperator]) +- [mainmatter/ember-simple-auth] + [#2802](https://github.com/mainmatter/ember-simple-auth/pull/2802) chore(ci): + add scenario against ember-lts-5.8 ([@BobrImperator]) +- [mainmatter/ember-simple-auth] + [#2801](https://github.com/mainmatter/ember-simple-auth/pull/2801) feat(deps): + update to ember-engines 0.11.0 ([@BobrImperator]) + +## Unknown + +- [ef4/prember] [#84](https://github.com/ef4/prember/pull/84) add release-plan + ([@mansona]) +- [ef4/prember] [#83](https://github.com/ef4/prember/pull/83) switch to pnpm and + fix tests ([@mansona]) +- [ef4/prember] [#82](https://github.com/ef4/prember/pull/82) recycle the + fastboot instance after 1k requests ([@mansona]) +- [ember-learn/ember-data-request-service-cheat-sheet] + [#15](https://github.com/ember-learn/ember-data-request-service-cheat-sheet/pull/15) + stop deploying to gh-pages since we're using netlify ([@mansona]) +- [ember-learn/ember-data-request-service-cheat-sheet] + [#14](https://github.com/ember-learn/ember-data-request-service-cheat-sheet/pull/14) + stop using rootUrl to fix netlify previews and deployments ([@mansona]) +- [mansona/testing-release-plan] + [#4](https://github.com/mansona/testing-release-plan/pull/4) add a description + ([@mansona]) +- [mansona/testing-release-plan] + [#1](https://github.com/mansona/testing-release-plan/pull/1) setup + release-plan ([@mansona]) + +[@BlueCutOfficial]: https://github.com/BlueCutOfficial +[@BobrImperator]: https://github.com/BobrImperator +[@mansona]: https://github.com/mansona +[@marcoow]: https://github.com/marcoow +[@nickschot]: https://github.com/nickschot +[@paoloricciuti]: https://github.com/paoloricciuti +[ef4/prember]: https://github.com/ef4/prember +[ember-learn/ember-api-docs-data]: + https://github.com/ember-learn/ember-api-docs-data +[ember-learn/ember-api-docs]: https://github.com/ember-learn/ember-api-docs +[ember-learn/ember-data-request-service-cheat-sheet]: + https://github.com/ember-learn/ember-data-request-service-cheat-sheet +[embroider-build/embroider]: https://github.com/embroider-build/embroider +[mainmatter/ember-cookies]: https://github.com/mainmatter/ember-cookies +[mainmatter/ember-simple-auth]: https://github.com/mainmatter/ember-simple-auth +[mainmatter/sheepdog]: https://github.com/mainmatter/sheepdog +[mansona/testing-release-plan]: https://github.com/mansona/testing-release-plan +[marcoow/pacesetter]: https://github.com/marcoow/pacesetter +[sveltejs/svelte]: https://github.com/sveltejs/svelte From 6878b9a402958f2f3636cb71d106353a4b1868a9 Mon Sep 17 00:00:00 2001 From: TWIOS Dev Date: Thu, 11 Jul 2024 17:59:09 +0000 Subject: [PATCH 2/6] Edited twios-2024-07-07 --- config/this-week-in-open-source.config.json | 9 ++++-- src/twios/2024-07-07.md | 34 ++++++++------------- 2 files changed, 18 insertions(+), 25 deletions(-) diff --git a/config/this-week-in-open-source.config.json b/config/this-week-in-open-source.config.json index b2ed45babb..17f97b4add 100644 --- a/config/this-week-in-open-source.config.json +++ b/config/this-week-in-open-source.config.json @@ -455,7 +455,9 @@ "yapplabs/ember-tether", "cibernox/ember-power-calendar", "ef4/decorator-transforms", - "adopted-ember-addons/ember-infinity" + "adopted-ember-addons/ember-infinity", + "ef4/prember", + "ember-learn/ember-data-request-service-cheat-sheet" ] }, { @@ -552,10 +554,11 @@ "tech-conferences/conference-data", "erlef/website", "oscard0m/example-probot-vercel-ts", - "paoloricciuti/darkmodething" + "paoloricciuti/darkmodething", + "mansona/testing-release-plan" ], "exclude_closed_not_merged": true, "output_path": "src/twios/", - "last_date": "", + "last_date": "2024-06-30..2024-07-07", "query_type": "Merged" } \ No newline at end of file diff --git a/src/twios/2024-07-07.md b/src/twios/2024-07-07.md index 6c0a3c4817..e69f977e66 100644 --- a/src/twios/2024-07-07.md +++ b/src/twios/2024-07-07.md @@ -36,12 +36,24 @@ ## Ember +- [ef4/prember] [#84](https://github.com/ef4/prember/pull/84) add release-plan + ([@mansona]) +- [ef4/prember] [#83](https://github.com/ef4/prember/pull/83) switch to pnpm and + fix tests ([@mansona]) +- [ef4/prember] [#82](https://github.com/ef4/prember/pull/82) recycle the + fastboot instance after 1k requests ([@mansona]) - [ember-learn/ember-api-docs] [#914](https://github.com/ember-learn/ember-api-docs/pull/914) fix require-expect lint ([@mansona]) - [ember-learn/ember-api-docs-data] [#30](https://github.com/ember-learn/ember-api-docs-data/pull/30) Fix names in source s3 files ([@mansona]) +- [ember-learn/ember-data-request-service-cheat-sheet] + [#15](https://github.com/ember-learn/ember-data-request-service-cheat-sheet/pull/15) + stop deploying to gh-pages since we're using netlify ([@mansona]) +- [ember-learn/ember-data-request-service-cheat-sheet] + [#14](https://github.com/ember-learn/ember-data-request-service-cheat-sheet/pull/14) + stop using rootUrl to fix netlify previews and deployments ([@mansona]) - [mainmatter/ember-cookies] [#946](https://github.com/mainmatter/ember-cookies/pull/946) chore(ci): strategy.fail-fast=false ([@BobrImperator]) @@ -58,27 +70,6 @@ [#2801](https://github.com/mainmatter/ember-simple-auth/pull/2801) feat(deps): update to ember-engines 0.11.0 ([@BobrImperator]) -## Unknown - -- [ef4/prember] [#84](https://github.com/ef4/prember/pull/84) add release-plan - ([@mansona]) -- [ef4/prember] [#83](https://github.com/ef4/prember/pull/83) switch to pnpm and - fix tests ([@mansona]) -- [ef4/prember] [#82](https://github.com/ef4/prember/pull/82) recycle the - fastboot instance after 1k requests ([@mansona]) -- [ember-learn/ember-data-request-service-cheat-sheet] - [#15](https://github.com/ember-learn/ember-data-request-service-cheat-sheet/pull/15) - stop deploying to gh-pages since we're using netlify ([@mansona]) -- [ember-learn/ember-data-request-service-cheat-sheet] - [#14](https://github.com/ember-learn/ember-data-request-service-cheat-sheet/pull/14) - stop using rootUrl to fix netlify previews and deployments ([@mansona]) -- [mansona/testing-release-plan] - [#4](https://github.com/mansona/testing-release-plan/pull/4) add a description - ([@mansona]) -- [mansona/testing-release-plan] - [#1](https://github.com/mansona/testing-release-plan/pull/1) setup - release-plan ([@mansona]) - [@BlueCutOfficial]: https://github.com/BlueCutOfficial [@BobrImperator]: https://github.com/BobrImperator [@mansona]: https://github.com/mansona @@ -95,6 +86,5 @@ [mainmatter/ember-cookies]: https://github.com/mainmatter/ember-cookies [mainmatter/ember-simple-auth]: https://github.com/mainmatter/ember-simple-auth [mainmatter/sheepdog]: https://github.com/mainmatter/sheepdog -[mansona/testing-release-plan]: https://github.com/mansona/testing-release-plan [marcoow/pacesetter]: https://github.com/marcoow/pacesetter [sveltejs/svelte]: https://github.com/sveltejs/svelte From 8bff0d93af11dc3ef041b0f1aba82b1d8654596d Mon Sep 17 00:00:00 2001 From: Marine Dunstetter Date: Tue, 9 Jul 2024 21:42:42 +0200 Subject: [PATCH 3/6] blog post: last embroider update --- src/posts/2024-07-16-embroider-update.md | 221 +++++++++++++++++++++++ 1 file changed, 221 insertions(+) create mode 100644 src/posts/2024-07-16-embroider-update.md diff --git a/src/posts/2024-07-16-embroider-update.md b/src/posts/2024-07-16-embroider-update.md new file mode 100644 index 0000000000..95ab22328b --- /dev/null +++ b/src/posts/2024-07-16-embroider-update.md @@ -0,0 +1,221 @@ +--- +title: "Embroider Initiative: Conclusion" +authorHandle: academierenards +tags: [ember, embroider] +bio: "Marine Dunstetter, Senior Software Engineer" +description: + "A summary of what Mainmatter achieved with the Embroider Initiative and what + are the next steps for the community." +og: + image: /assets/images/posts/2024-05-29-embroider-update/og-image.jpg +tagline: | +

+ The Embroider initiative was a big success for the Ember ecosystem that opened the door to building Ember apps with Vite. Having two engineers work full-time on Embroider allowed many important achievements toward that goal. In this blog post, we will look back at the roadmap to present how far we could go, what are the next steps for the community, and how Mainmatter can make them happen through the new [Ember Initiative](/ember-initiative/). +

+ +image: /assets/images/posts/2024-05-29-embroider-update/header-embroider.jpg +imageAlt: + "The logo of companies supporting the Embroider Initiative on a background + showing people working together on a laptop" +--- + +Over the past year, the Embroider Initiative has opened the door to building +Ember apps with Vite, porting Ember back into any conversation about modern +frameworks. Ember has started to be noticed in a wider community and remains a +good choice in 2024, thanks to everything that was accomplished through the +Embroider Initiative and all the companies that invested to make it happen. The +Embroider Initiative now comes to an end, but it's only a new beginning for the +Ember ecosystem. Let's dive into the state of the roadmap and what next steps +have been unblocked by the achieved pieces. + +## 1. Implement the core of Embroider + +The biggest part of the work so far was of course to implement the core of +Embroider. The +[lastest blog post from May](https://mainmatter.com/blog/2024/05/29/embroider-update/) +is a good summary of the different steps of the implementation. In even shorter +words: + +- Stage 1 (achieved in the 1st half of the initiative): To achieve backward + compatibility, each classic Ember Addon package is rebuilt into a new v2 + package format stored in a `rewritten-packages` folder, more static and + analyzable. + +- Stage 2 (achieved in the 1st half of the initiative): By default, Ember apps + can't be built with Vite because they rely on features Vite cannot understand. + To work around this problem, Embroider generates a `rewritten-app`, which is + slightly different from the initial Ember app in a way it can be consumed by + Vite. But the generation of this rewritten app is an extra step that comes + with performance downsides. + +- Stage 3 (team's focus on the 2nd half of the initiative): To optimize the Vite + build, we have started a wide technical topic called “inversion of control”. + The idea is that instead of having Embroider produce a rewritten app, and then + passing over to Vite once the rewritten app is ready, Vite takes the lead, and + when it’s unable to resolve Ember-specific requests, it asks Embroider to + return the information without the need of a rewritten app. + +### a. Optimize the Vite build with inversion of control + +To put it very simply: Vite cannot build the initial Ember app, but the +rewritten app can, so we are going to remove all the differences between both +apps so Vite can consume the initial Ember app directly... easier said than done +though, because the rewritten app is allowed to rely on files generated during +the build process that cannot be part of the Ember app code base. When one of +these nonexisting files is requested to the Vite dev server, Embroider must be +able to return a consistent answer on the spot as virtual content. On the other +hand, part of these virtual content must be emitted as assets for the production +build, and now this has to be done by Vite through custom plugins. Files +virtualization came with its set of challenges, like finding the right approach +to deal with Vite specifics in a way that keeps Embroider core bundler-agnostic. + +🐹 _What's next:_ During the Embroider initiative, we have reached a point where +we are very close to removing the need for the rewritten app completely; there +are a few tasks left that are interdependent and already in progress. Also, to +work on the inversion of control, we had to stop Webpack support, which doesn't +use this new approach. Once the rewritten app is removed, one important next +step will be to re-implement Webpack support with the inversion of control +approach, and therefore prove Embroider is truly bundler-agnostic. + +### b. Maintain the compatibility of all classic features + +A very wide part of the inversion of control is related to maintaining classic +functionalities and keeping v1 addons working the way they used to work in +classic builds. For instance, it makes sense that Vite generates a `vendor.css` +file in the production build only if some classic addon provides styles to +include in there; it makes sense that Embroider is able to locate an addon's +public asset in the rewritten packages and to return its path to the Vite dev +server only because that addon provides that public asset. Classic addons can +also implement hooks like `contentFor` that transform the content of the app's +`index.html`, and many other things. + +We could create the rewritten app directly the way it needed to be so all these +features work. With inversion of control, the purpose of each classic +functionality must be carefully thought out so we decide what's the best new way +to handle it. For instance: + +- **We want to keep this feature as it is**: As Vite is now in charge of the + build, it should now be responsible for tasks that were previously handled by + Broccoli plugins, like emitting assets in the production build, or + transforming the `index.html`. This is what was done for `vendor.js`, + `vendor.css`, `test-support.js`, `test-support.css`, public assets, + `content-for` snippets in `index.html`, initializers and + instance-initializers... When it comes to upgrading v1 addons to v2, + `@embroider/macros` is also a way to keep v2 addons "dynamic" by using Babel + to transform addon code depending on the app build environment and options. + +- **This should now be the responsibility of the app**: because Ember does a lot + of things under the hood, classic addons ended up implementing capabilities to + modify app code the developer cannot access, they kind of "come with their own + configuration" instead of "explain how they should be configured". This is + something that will change in modern Ember apps. For instance, classic addons + could use the `contentFor` hook to change the way the app boots. In the new + Ember app format, the developer will have access to the app-boot script + directly in the `index.html`, so addons no longer need to try modifying it + under the hood. Instead of supporting this feature, we decided to implement + the detection of this hook being used and an informative message about how to + update the app. The same rationale was used for `contentFor 'config-module'`. + +- **We may not want to support this anymore**: some features have been + deprioritized because we question their purpose. One example is the + `serverMiddleware` hook. This hook allowed you to make changes to the express + server run by ember-cli. This dev-only concept disappears with Vite, since we + rely on the Vite dev server. Do we really want a way to re-implements in Vite + middlewares what `serverMiddleware` hook was doing considering that, at the + very beginning, this feature creates a big gap between testing the app in dev + mode and production mode? There are probably better ways to make the test + closer to a “production context”. + +🐹 _What's next:_ During the Embroider Initiative, we prioritized the support of +the most important classic features, that are widely used by the community. Some +other less used features are not supported yet, like FastBoot, or storing the +environment config in JS rather than `index.html` meta. The issue +[embroider-build/embroider#1860](https://github.com/embroider-build/embroider/issues/1860) +contains a list of identified features that still require work. + +## 2. Supports older Ember versions + +Embroider uses a tool called scenario-tester to test many apps and addons +scenarios against different Ember versions. Currently, the Vite branch of the +Embroider project runs against Ember 5.8 and canary, which means you need to +upgrade your app to the latest Ember to build with Vite. + +Recently, we have been working hard on improving the scenario-tester and having +the stable branch run against Ember 3.28 and above. This work includes an +important fix for ember-data 4.x: the latest improvements on the scenario-tester +fixed the way some dependencies are managed, which highlighted false positives +in the test suite and reproduced errors encountered by developers in their apps. +This allowed us to find the root cause and fix Embroider to manage correctly +ember-data 4.x and any addon that may behave the same way. Not only did this +work on the stable branch positively impact apps using Embroider Stable, but it +also paved the ground to support older Ember versions in Vite. + +🐹 _What's next:_ Ideally, we would like to bring the Vite build to Ember 3.28, +as it's the oldest version supported on Embroider Stable. The task will +essentially consist of fixing circular dependencies in ember-source to get a +correct ESM graph. Functionalities like assert, debug, deprecate… need to be +patched in older Ember versions. The idea is to implement a set of patches for +each version we want to support. + +## 3. Stabilize the app blueprint + +The implementation of the core of Embroider drives a new authoring format for +modern Ember apps. The approach we choose to answer compatibility questions +always tends toward making modern Ember apps more standardized. Between +Embroider Stable and Embroider Vite, the shape of the Ember app has changed +quite a bit. Among other things: the developer now has full control over the +app-boot module (which is now an in-html script in `index.html`) and the config +environment module (which is located in `app/config/environment.js`), a part of +the scripts are virtual modules identified by a virtual identifier starting with +`@embroider`, the AMD modules brought by classic addons are now defined in +`app/app.js` to get the notion of AMD out of Embroider and pave the ground to a +new resolver with +[strict ESM support](https://github.com/emberjs/rfcs/pull/938/), etc... + +Some tasks are only about making the Ember apps more standard and comprehensible +without being directly related to compatibility questions. It's the case of the +Babel config topic we opened. Any classic Ember app depends on ember-cli-babel, +which builds a set of Babel plugins the app requires to run correctly. +ember-cli-babel can be controlled through some build options. In modern Ember +apps, the `babel.config.cjs` file will be responsible for the Babel config, and +the power to control Babel should not be split between `babel.config.cjs` and +build options. We are currently working on removing the mandatory dependency to +ember-cli-babel by creating a `babel.config.cjs` made-for-Ember that will be +provided in... the app blueprint. + +On May 31st, Chris presented at EmberConf the +[app blueprint](https://github.com/embroider-build/app-blueprint) that allows +people to generate an Ember app building with Vite from the start. The CI runs +against the Vite branch of Embroider, so each time we merge something, we can +see if the app generated by the blueprint runs correctly. An important step of +Embroider development is to answer all the questions that allow us to define +what the app blueprint looks like, and therefore what developers start with when +creating a brand new app. + +🐹 _What's next:_ Now that we have a good idea of what a modern Ember app looks +like, an important next step is to describe it in an RFC to introduce it to the +community and open the door to potential discussions and improvements. + +## 4. Handover + +The Embroider Initiative now comes to a - successful - end; We have achieved so +many important pieces and we are proud to see the first Ember apps in the +community making their way to Vite. It's now up to the Ember community to pursue +the implementation of Embroider: achieve the topics that remain open, challenge +the blueprint to make Ember as intuitive as possible, support the classic +features that are still wanted, enhance the documentation, make sure all the +most popular addons work with Vite... To ease the handover, the public GitHub +project +[Embroider Working Group](https://github.com/orgs/embroider-build/projects/2) +has been created to help future contributors keep track of the existing issues +and their current status. + +Over the past year, our team at Mainmatter has built a solid knowledge of +Embroider's core. We can help the Ember community push Embroider further and +further if you give us the means to do it. We’re proposing to turn the Embroider +Initiative into a permanent effort – the Ember Initiative. Mainmatter will +continue to assign a team to work on Ember and its ecosystem full-time. They +will address topics relevant to the Ember ecosystem and every company that uses +Ember. Polish Embroider is part of the main topics we're proposing. Check out +our [Ember Initiative](/ember-initiative/) page and our dedicated blog post +[The Embroider Initiative Becomes the Ember Initiative](/blog/2024/07/09/the-embroider-initiative-becomes-the-ember-initiative/). From 70c460cc3724333ca8738e695fb524e09821575c Mon Sep 17 00:00:00 2001 From: Marine Dunstetter Date: Fri, 12 Jul 2024 16:16:37 +0200 Subject: [PATCH 4/6] blog post: apply the review comments --- src/posts/2024-07-16-embroider-update.md | 73 +++++++++++++----------- 1 file changed, 41 insertions(+), 32 deletions(-) diff --git a/src/posts/2024-07-16-embroider-update.md b/src/posts/2024-07-16-embroider-update.md index 95ab22328b..bd0bdd5aa2 100644 --- a/src/posts/2024-07-16-embroider-update.md +++ b/src/posts/2024-07-16-embroider-update.md @@ -10,7 +10,7 @@ og: image: /assets/images/posts/2024-05-29-embroider-update/og-image.jpg tagline: |

- The Embroider initiative was a big success for the Ember ecosystem that opened the door to building Ember apps with Vite. Having two engineers work full-time on Embroider allowed many important achievements toward that goal. In this blog post, we will look back at the roadmap to present how far we could go, what are the next steps for the community, and how Mainmatter can make them happen through the new [Ember Initiative](/ember-initiative/). + The Embroider initiative was a big success for the Ember ecosystem that opened the door to building Ember apps with Vite. Having two engineers work full-time on Embroider allowed many important achievements towards that goal. In this blog post, we will look back at the roadmap to present how far we could go, what are the next steps for the community, and how Mainmatter can make them happen through the new [Ember Initiative](/ember-initiative/).

image: /assets/images/posts/2024-05-29-embroider-update/header-embroider.jpg @@ -20,13 +20,12 @@ imageAlt: --- Over the past year, the Embroider Initiative has opened the door to building -Ember apps with Vite, porting Ember back into any conversation about modern +Ember apps with Vite, raising Ember back up to the same level as other modern frameworks. Ember has started to be noticed in a wider community and remains a good choice in 2024, thanks to everything that was accomplished through the -Embroider Initiative and all the companies that invested to make it happen. The -Embroider Initiative now comes to an end, but it's only a new beginning for the -Ember ecosystem. Let's dive into the state of the roadmap and what next steps -have been unblocked by the achieved pieces. +Embroider Initiative and all the companies that invested to make it happen. As +the Embroider Initiative becomes the Ember Initiative, let's take a look at what +we achieved so far and the next steps that are now possible. ## 1. Implement the core of Embroider @@ -55,27 +54,36 @@ words: when it’s unable to resolve Ember-specific requests, it asks Embroider to return the information without the need of a rewritten app. +The sections below provide an overview of Stage 3, which consists of gradually +replacing a large proportion of Stage 2 behaviors with this new “inversion of +control” approach. + ### a. Optimize the Vite build with inversion of control -To put it very simply: Vite cannot build the initial Ember app, but the -rewritten app can, so we are going to remove all the differences between both +To put it very simply: Vite cannot build the initial Ember app, but it can build +the rewritten app, so we are going to remove all the differences between both apps so Vite can consume the initial Ember app directly... easier said than done -though, because the rewritten app is allowed to rely on files generated during -the build process that cannot be part of the Ember app code base. When one of -these nonexisting files is requested to the Vite dev server, Embroider must be -able to return a consistent answer on the spot as virtual content. On the other -hand, part of these virtual content must be emitted as assets for the production -build, and now this has to be done by Vite through custom plugins. Files -virtualization came with its set of challenges, like finding the right approach -to deal with Vite specifics in a way that keeps Embroider core bundler-agnostic. +though, because the rewritten app is allowed to contain files generated during +the build process that cannot be part of the Ember app code base. When these +nonexisting files are requested to the Vite dev server, Embroider must be able +to return a consistent answer on the spot as virtual content. The clearest +example is probably the vendor file. In classic apps, `index.html` contains a +reference to `{{rootURL}}assets/vendor.js`, which points to a file created +during the classic build pipeline. When using Vite, this reference must be +replaced with `/@embroider/core/vendor.js`, a virtual identifier that will tell +Vite to ask Embroider for the content. On the other hand, part of these virtual +content must be emitted as assets for the production build, and now this has to +be done by Vite through custom plugins. Files virtualization came with its set +of challenges, like finding the right approach to deal with Vite specifics in a +way that keeps Embroider core bundler-agnostic. 🐹 _What's next:_ During the Embroider initiative, we have reached a point where we are very close to removing the need for the rewritten app completely; there are a few tasks left that are interdependent and already in progress. Also, to work on the inversion of control, we had to stop Webpack support, which doesn't -use this new approach. Once the rewritten app is removed, one important next -step will be to re-implement Webpack support with the inversion of control -approach, and therefore prove Embroider is truly bundler-agnostic. +use this new approach. Once the rewritten app is removed, one next step will be +to re-implement Webpack support with the inversion of control approach, and +therefore prove Embroider is truly bundler-agnostic. ### b. Maintain the compatibility of all classic features @@ -92,7 +100,7 @@ also implement hooks like `contentFor` that transform the content of the app's We could create the rewritten app directly the way it needed to be so all these features work. With inversion of control, the purpose of each classic functionality must be carefully thought out so we decide what's the best new way -to handle it. For instance: +to handle it. There are three categories of such features: - **We want to keep this feature as it is**: As Vite is now in charge of the build, it should now be responsible for tasks that were previously handled by @@ -133,7 +141,7 @@ environment config in JS rather than `index.html` meta. The issue [embroider-build/embroider#1860](https://github.com/embroider-build/embroider/issues/1860) contains a list of identified features that still require work. -## 2. Supports older Ember versions +## 2. Support older Ember versions Embroider uses a tool called scenario-tester to test many apps and addons scenarios against different Ember versions. Currently, the Vite branch of the @@ -173,15 +181,15 @@ new resolver with [strict ESM support](https://github.com/emberjs/rfcs/pull/938/), etc... Some tasks are only about making the Ember apps more standard and comprehensible -without being directly related to compatibility questions. It's the case of the -Babel config topic we opened. Any classic Ember app depends on ember-cli-babel, -which builds a set of Babel plugins the app requires to run correctly. -ember-cli-babel can be controlled through some build options. In modern Ember -apps, the `babel.config.cjs` file will be responsible for the Babel config, and -the power to control Babel should not be split between `babel.config.cjs` and -build options. We are currently working on removing the mandatory dependency to -ember-cli-babel by creating a `babel.config.cjs` made-for-Ember that will be -provided in... the app blueprint. +without being directly related to compatibility questions. That's the case for +the Babel's config for example. Any classic Ember app depends on +ember-cli-babel, which builds a set of Babel plugins the app requires to run +correctly. ember-cli-babel can be controlled through some build options. In +modern Ember apps, the `babel.config.cjs` file will be responsible for the Babel +config, and the power to control Babel should not be split between +`babel.config.cjs` and build options. We are currently working on removing the +mandatory dependency to ember-cli-babel by creating a `babel.config.cjs` +made-for-Ember that will be provided in... the app blueprint. On May 31st, Chris presented at EmberConf the [app blueprint](https://github.com/embroider-build/app-blueprint) that allows @@ -208,7 +216,8 @@ most popular addons work with Vite... To ease the handover, the public GitHub project [Embroider Working Group](https://github.com/orgs/embroider-build/projects/2) has been created to help future contributors keep track of the existing issues -and their current status. +and their current status. We plan to work on some of these issues as part of the +[Ember initiative](/blog/2024/07/09/the-embroider-initiative-becomes-the-ember-initiative/). Over the past year, our team at Mainmatter has built a solid knowledge of Embroider's core. We can help the Ember community push Embroider further and @@ -216,6 +225,6 @@ further if you give us the means to do it. We’re proposing to turn the Embroid Initiative into a permanent effort – the Ember Initiative. Mainmatter will continue to assign a team to work on Ember and its ecosystem full-time. They will address topics relevant to the Ember ecosystem and every company that uses -Ember. Polish Embroider is part of the main topics we're proposing. Check out +Ember. Polishing Embroider is part of the main topics we're proposing. Check out our [Ember Initiative](/ember-initiative/) page and our dedicated blog post [The Embroider Initiative Becomes the Ember Initiative](/blog/2024/07/09/the-embroider-initiative-becomes-the-ember-initiative/). From aaa393b7d705f980e42d5c69ad0ffec364bc0d07 Mon Sep 17 00:00:00 2001 From: Marine Dunstetter Date: Fri, 12 Jul 2024 16:34:09 +0200 Subject: [PATCH 5/6] blog post: fix header link and rootUrl --- src/posts/2024-07-16-embroider-update.md | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/src/posts/2024-07-16-embroider-update.md b/src/posts/2024-07-16-embroider-update.md index bd0bdd5aa2..88de9cfdfc 100644 --- a/src/posts/2024-07-16-embroider-update.md +++ b/src/posts/2024-07-16-embroider-update.md @@ -10,7 +10,7 @@ og: image: /assets/images/posts/2024-05-29-embroider-update/og-image.jpg tagline: |

- The Embroider initiative was a big success for the Ember ecosystem that opened the door to building Ember apps with Vite. Having two engineers work full-time on Embroider allowed many important achievements towards that goal. In this blog post, we will look back at the roadmap to present how far we could go, what are the next steps for the community, and how Mainmatter can make them happen through the new [Ember Initiative](/ember-initiative/). + The Embroider initiative was a big success for the Ember ecosystem that opened the door to building Ember apps with Vite. Having two engineers work full-time on Embroider allowed many important achievements towards that goal. In this blog post, we will look back at the roadmap to present how far we could go, what are the next steps for the community, and how Mainmatter can make them happen through the new Ember Initiative.

image: /assets/images/posts/2024-05-29-embroider-update/header-embroider.jpg @@ -68,14 +68,14 @@ the build process that cannot be part of the Ember app code base. When these nonexisting files are requested to the Vite dev server, Embroider must be able to return a consistent answer on the spot as virtual content. The clearest example is probably the vendor file. In classic apps, `index.html` contains a -reference to `{{rootURL}}assets/vendor.js`, which points to a file created -during the classic build pipeline. When using Vite, this reference must be -replaced with `/@embroider/core/vendor.js`, a virtual identifier that will tell -Vite to ask Embroider for the content. On the other hand, part of these virtual -content must be emitted as assets for the production build, and now this has to -be done by Vite through custom plugins. Files virtualization came with its set -of challenges, like finding the right approach to deal with Vite specifics in a -way that keeps Embroider core bundler-agnostic. +reference to `assets/vendor.js` (prefixed by the root URL), which points to a +file created during the classic build pipeline. When using Vite, this reference +must be replaced with `/@embroider/core/vendor.js`, a virtual identifier that +will tell Vite to ask Embroider for the content. On the other hand, part of +these virtual content must be emitted as assets for the production build, and +now this has to be done by Vite through custom plugins. Files virtualization +came with its set of challenges, like finding the right approach to deal with +Vite specifics in a way that keeps Embroider core bundler-agnostic. 🐹 _What's next:_ During the Embroider initiative, we have reached a point where we are very close to removing the need for the rewritten app completely; there From e86668606a5884115394a928ddca9daf47d57124 Mon Sep 17 00:00:00 2001 From: Chris Manson Date: Tue, 16 Jul 2024 15:03:57 +0100 Subject: [PATCH 6/6] Apply changes directly (#2493) * apply changes to embroider blog post * lint fix --- src/posts/2024-07-16-embroider-update.md | 139 ++++++++++++----------- 1 file changed, 71 insertions(+), 68 deletions(-) diff --git a/src/posts/2024-07-16-embroider-update.md b/src/posts/2024-07-16-embroider-update.md index 88de9cfdfc..d6284cf74d 100644 --- a/src/posts/2024-07-16-embroider-update.md +++ b/src/posts/2024-07-16-embroider-update.md @@ -20,14 +20,15 @@ imageAlt: --- Over the past year, the Embroider Initiative has opened the door to building -Ember apps with Vite, raising Ember back up to the same level as other modern -frameworks. Ember has started to be noticed in a wider community and remains a -good choice in 2024, thanks to everything that was accomplished through the -Embroider Initiative and all the companies that invested to make it happen. As -the Embroider Initiative becomes the Ember Initiative, let's take a look at what -we achieved so far and the next steps that are now possible. +Ember apps with Vite, bringing Ember's build system more in line with other +modern frameworks. Ember has started to be noticed in the wider Javascript +community and remains a good choice in 2024, thanks to everything that was +accomplished through the Embroider Initiative and all the companies that +invested to make it happen. As the Embroider Initiative becomes the Ember +Initiative, let's take a look at what we achieved so far and the next steps that +are now possible. -## 1. Implement the core of Embroider +## Implement the core of Embroider The biggest part of the work so far was of course to implement the core of Embroider. The @@ -35,30 +36,28 @@ Embroider. The is a good summary of the different steps of the implementation. In even shorter words: -- Stage 1 (achieved in the 1st half of the initiative): To achieve backward - compatibility, each classic Ember Addon package is rebuilt into a new v2 - package format stored in a `rewritten-packages` folder, more static and - analyzable. +- To achieve backward compatibility, each classic Ember Addon package is rebuilt + into a new v2 package format stored in a `rewritten-packages` folder, more + static and analyzable. -- Stage 2 (achieved in the 1st half of the initiative): By default, Ember apps - can't be built with Vite because they rely on features Vite cannot understand. - To work around this problem, Embroider generates a `rewritten-app`, which is - slightly different from the initial Ember app in a way it can be consumed by - Vite. But the generation of this rewritten app is an extra step that comes - with performance downsides. +- By default, Ember apps can't be built with Vite because they rely on features + Vite cannot understand. To work around this problem, Embroider generates a + `rewritten-app`, which is slightly different from the initial Ember app in a + way it can be consumed by Vite. But the generation of this rewritten app is an + extra step that comes with performance downsides. -- Stage 3 (team's focus on the 2nd half of the initiative): To optimize the Vite - build, we have started a wide technical topic called “inversion of control”. - The idea is that instead of having Embroider produce a rewritten app, and then - passing over to Vite once the rewritten app is ready, Vite takes the lead, and - when it’s unable to resolve Ember-specific requests, it asks Embroider to - return the information without the need of a rewritten app. +- To optimize the Vite build, we have started a wide technical topic called + “Inversion of Control”. The idea is that instead of having Embroider produce a + rewritten app, and then passing over to Vite once the rewritten app is ready, + Vite takes the lead, and when it’s unable to resolve Ember-specific requests, + it asks Embroider to return the information without the need of a rewritten + app. -The sections below provide an overview of Stage 3, which consists of gradually -replacing a large proportion of Stage 2 behaviors with this new “inversion of -control” approach. +The sections below provide an overview of this "Inversion of Control" process, +which consists of gradually replacing a large proportion of the `rewritten-app` +with this virtual content that Vite can understand -### a. Optimize the Vite build with inversion of control +### Optimize the Vite build with inversion of control To put it very simply: Vite cannot build the initial Ember app, but it can build the rewritten app, so we are going to remove all the differences between both @@ -85,7 +84,7 @@ use this new approach. Once the rewritten app is removed, one next step will be to re-implement Webpack support with the inversion of control approach, and therefore prove Embroider is truly bundler-agnostic. -### b. Maintain the compatibility of all classic features +### Maintain the compatibility of all classic features A very wide part of the inversion of control is related to maintaining classic functionalities and keeping v1 addons working the way they used to work in @@ -141,22 +140,22 @@ environment config in JS rather than `index.html` meta. The issue [embroider-build/embroider#1860](https://github.com/embroider-build/embroider/issues/1860) contains a list of identified features that still require work. -## 2. Support older Ember versions +## Support older Ember versions Embroider uses a tool called scenario-tester to test many apps and addons scenarios against different Ember versions. Currently, the Vite branch of the Embroider project runs against Ember 5.8 and canary, which means you need to upgrade your app to the latest Ember to build with Vite. -Recently, we have been working hard on improving the scenario-tester and having -the stable branch run against Ember 3.28 and above. This work includes an -important fix for ember-data 4.x: the latest improvements on the scenario-tester -fixed the way some dependencies are managed, which highlighted false positives -in the test suite and reproduced errors encountered by developers in their apps. -This allowed us to find the root cause and fix Embroider to manage correctly +Recently, we have been working hard on improving scenario-tester and having the +stable branch run against Ember 3.28 and above. This work includes an important +fix for ember-data 4.x: the latest improvements on scenario-tester fixed the way +some dependencies are managed, which highlighted false positives in the test +suite and reproduced errors encountered by developers in their apps. This +allowed us to find the root cause and fix Embroider to correctly manage ember-data 4.x and any addon that may behave the same way. Not only did this -work on the stable branch positively impact apps using Embroider Stable, but it -also paved the ground to support older Ember versions in Vite. +work positively impact the stable branch of Embroider, it also laid the +groundwork to support older Ember versions in Vite. 🐹 _What's next:_ Ideally, we would like to bring the Vite build to Ember 3.28, as it's the oldest version supported on Embroider Stable. The task will @@ -165,7 +164,7 @@ correct ESM graph. Functionalities like assert, debug, deprecate… need to be patched in older Ember versions. The idea is to implement a set of patches for each version we want to support. -## 3. Stabilize the app blueprint +## Stabilize the app blueprint The implementation of the core of Embroider drives a new authoring format for modern Ember apps. The approach we choose to answer compatibility questions @@ -189,14 +188,14 @@ modern Ember apps, the `babel.config.cjs` file will be responsible for the Babel config, and the power to control Babel should not be split between `babel.config.cjs` and build options. We are currently working on removing the mandatory dependency to ember-cli-babel by creating a `babel.config.cjs` -made-for-Ember that will be provided in... the app blueprint. - -On May 31st, Chris presented at EmberConf the -[app blueprint](https://github.com/embroider-build/app-blueprint) that allows -people to generate an Ember app building with Vite from the start. The CI runs -against the Vite branch of Embroider, so each time we merge something, we can -see if the app generated by the blueprint runs correctly. An important step of -Embroider development is to answer all the questions that allow us to define +made-for-Ember that will be provided in a new app blueprint. + +On May 31st, Chris presented at EmberConf and introduced the +[new Vite app blueprint](https://github.com/embroider-build/app-blueprint) that +allows people to generate an Ember app building with Vite from the start. The CI +runs against the Vite branch of Embroider, so each time we merge something, we +can see if the app generated by the blueprint runs correctly. An important step +of Embroider development is to answer all the questions that allow us to define what the app blueprint looks like, and therefore what developers start with when creating a brand new app. @@ -204,27 +203,31 @@ creating a brand new app. like, an important next step is to describe it in an RFC to introduce it to the community and open the door to potential discussions and improvements. -## 4. Handover - -The Embroider Initiative now comes to a - successful - end; We have achieved so -many important pieces and we are proud to see the first Ember apps in the -community making their way to Vite. It's now up to the Ember community to pursue -the implementation of Embroider: achieve the topics that remain open, challenge -the blueprint to make Ember as intuitive as possible, support the classic -features that are still wanted, enhance the documentation, make sure all the -most popular addons work with Vite... To ease the handover, the public GitHub -project -[Embroider Working Group](https://github.com/orgs/embroider-build/projects/2) -has been created to help future contributors keep track of the existing issues -and their current status. We plan to work on some of these issues as part of the -[Ember initiative](/blog/2024/07/09/the-embroider-initiative-becomes-the-ember-initiative/). +## Handover + +The Embroider Initiative has come to a successful end; We have achieved so much +and we are proud to see some Ember apps in the community making their way to +Vite. As it currently stands, it's now up to the Ember Community to continue the +implementation of Embroider. To facilitate the handover from the Embroider +Initiative, we created the public GitHub project +[Embroider Working Group](https://github.com/orgs/embroider-build/projects/2) to +help future contributors keep track of the existing issues and their current +status. + +We at Mainmatter want to continue investing into the Ember ecosystem which is +why we're starting the Ember initiative as a successor to the Embroider +initiative. The Ember Initiative will not be focused on a single topic like the +Embroider Initiative, it will instead address a number of topics relevant to the +Ember ecosystem and every company that uses Ember. Polishing Embroider and +making it the default experience for new Ember apps is part of the main topics +we're proposing. Check out our [Ember Initiative](/ember-initiative/) page and +our dedicated blog post +[The Embroider Initiative Becomes the Ember Initiative](/blog/2024/07/09/the-embroider-initiative-becomes-the-ember-initiative/). + +## Conclusion Over the past year, our team at Mainmatter has built a solid knowledge of -Embroider's core. We can help the Ember community push Embroider further and -further if you give us the means to do it. We’re proposing to turn the Embroider -Initiative into a permanent effort – the Ember Initiative. Mainmatter will -continue to assign a team to work on Ember and its ecosystem full-time. They -will address topics relevant to the Ember ecosystem and every company that uses -Ember. Polishing Embroider is part of the main topics we're proposing. Check out -our [Ember Initiative](/ember-initiative/) page and our dedicated blog post -[The Embroider Initiative Becomes the Ember Initiative](/blog/2024/07/09/the-embroider-initiative-becomes-the-ember-initiative/). +Embroider's core and we have helped Embroider clear the monumental hurdle that +has been enabling Vite support. We can help the Ember community cross the finish +line with Embroider and continue to improve Ember and its ecosystem if you give +us the means to do it by backing the Ember Initiative.