Who am I?

Chris Ember Suzie and rodney

History of Ember

history

What even is Ember

batteries included

Ember's Innovation

ES Classes

ES Modules

Build Systems

Classes in JavaScript. They actually happened with Ember's help, Ember Core Team members were working with TC39 at the time they were being added. ES modules - we were using them as part of our authoring format before they were added to JavaScript. ember-cli, our baked in build system, was so ahead of its time that there were many arguments about if frameworks even needed a build system at the time that it came out. And since we're all here at ViteConf, I guess the team build system has won that particular battle!!

but with all those firsts we have a few problems, expeicially because we care so much about stability and not leaving anyone behind. our pree-class "class" object was the basis for all the major building blocks of the framework. We've cleaned up a bunch of them but still not all of them

Our module system...

Fake Modules

// Not a real package 🫠
import Something from '@ember/something';

gets magically converted to

import Something from 'ember-source/something/index';

🔔 FORESHADOWING!! 🔔

Broccoli

🥦

Pipeline

pipeline

sure it was sophisticated for its time but.. broccoli has a core assumption that your files are represented as a tree (essentially the same way that your operating system looks at them). But the cool thing is that you get a pipeline of trees where any file can be changed, files can be added, removed. It's all really powerful... but I wonder if any of you have seen the issue with a system like this. It doesn't match the modern build system concept of starting at an entrypoint and walking the module graph. With broccoli you have to work on whole trees all the time and you have very little knowledge about which modules are being used so you can't make the build any more efficient and you can't do any code splitting or tree shaking (ironcally - all trees with no shaking 😭).

so how do we marry these two worlds? How do we bring Ember into a world where we need to understand the module graph?

Embroider

foe

embroider

Embroider is our answer. Embroider is like a semi-magical glue code that bridges the gap beween the old way of doing things in Ember and the new. It allows you to use all of your existing ember concepts like addons, strange fake modules, automatic file discovery etc but it essentially pre-processes all your ember-cli based broccoli trees and outputs a (semi) prestine app that a bundler can look at and do its magic.

Woo hoo, problem solved let's ship Embroider to everyone! ... not so fast. literally.

The previous version of Embroider only works with webpack and it wasn't all that big of a sell for people. It would work 80% of the time, so most apps could use it, but when it broke it would break in weird and wonderful ways that were very hard to understand. Some of this was because Webpack's errors can be cryptic at the best of times but one of the fundemental issues that we were facing was that we were crowbaring a bundler into an outdated build paragdime of these broccoli trees. Even Webpack wasn't designed to work this way.

We were stuck without a plan until...

vite on the hill

Serious about Modules!

eval define

🤢

The second issue that we had was that Vite takes ES modules seriously. Sure we were pioneers in the use of modules in ember but that was mostly just authoring format. ember-cli rebuilt everything into AMD modules under the hood

🙈

not great, but what is worse is that even with Embroider and Webpack doing its magic... it all boiled down to a horrible AMD with webpack eval monstrocity in the build output.

SLIDE

I know you can't see it in this screenshot but there is a bunch of AMD requires and defines in that eval script too... not great

If we were serious about Vite we needed to get serious about modules and clean up our act.

Now we had the bones of a plan but there was a tonne of work still to do, it was going to take a long time for a fully open source community project like Ember if we didn't change the script.

Embroider Initative

logos

🎉

Try it out!

npx ember-cli@latest new my-fancy-app -b @embroider/app-blueprint

Follow the progress

rfc screenshot

https://github.com/emberjs/rfcs/pull/977

Deep Dive

resolveId()

async resolveId(source, importer, options) {
  let request = RollupModuleRequest.from(
    this, source, importer, options.custom);
  
  let resolution = await resolverLoader.resolver.resolve(request);
  switch (resolution.type) {
    case 'found':
    case 'ignored':
      return resolution.result;
    case 'not_found':
      return null;
  }
},

Three stages of Embroider

Stage 1

convert all your addons

Stage 2

convert your app

Stage 3

Pass your converted app and addons over to your bundler

That's vite 🎉

ace objection

Resolver Config

{
  "renameModules": {
    "@ember/object/computed.js": "ember-source/@ember/object/computed.js",
  },
  "renamePackages": {
    "live-reload-middleware": "ember-cli-inject-live-reload"
  },
  "engines": [{
    "activeAddons": [{
      "name": "@ember/test-helpers",
      "root": "/tmp/my-fancy-app/node_modules/.embroider/rewritten-packages/@ember/test-helpers.bfec475c/node_modules/@ember/test-helpers",
      "canResolveFromFile": "/tmp/my-fancy-app/package.json"
    }],
  }],
}

^*18 of the 400 lines in this file from a basic boilerplate app 🙈

resolveId() again

async resolveId(source, importer, options) {
  let request = RollupModuleRequest.from(
    this, source, importer, options.custom);
  
  let resolution = await resolverLoader.resolver.resolve(request);
  switch (resolution.type) {
    case 'found':
    case 'ignored':
      return resolution.result;
    case 'not_found':
      return null;
  }
},

Embroider's Resolve

async resolve(request) {
  request = await this.beforeResolve(request);
  if (request.resolvedTo) {
    return request.resolvedTo;
  }

  let resolution = await request.defaultResolve();
  switch (resolution.type) {
    case 'found':
      return resolution;
    case 'not_found':
      break;
  }
  let nextRequest = await this.fallbackResolve(request);
  if (nextRequest === request) {
    // no additional fallback is available.
    return resolution;
  }
  // do some other post-fallback stuff
}

Embroider's Before Resolve

private async beforeResolve(request) {
  request = await this.handleGlobalsCompat(request);
  request = this.handleImplicitModules(request);
  request = this.handleImplicitTestScripts(request);
  request = this.handleVendorStyles(request);
  request = this.handleTestSupportStyles(request);
  request = this.handleEntrypoint(request);
  request = this.handleRouteEntrypoint(request);
  request = this.handleRenaming(request);
  request = this.handleVendor(request);
  request = this.preHandleExternal(request);

  // this should probably stay the last step in beforeResolve, because it can
  // rehome requests to their un-rewritten locations, and for the most part we
  // want to be dealing with the rewritten packages.
  request = this.handleRewrittenPackages(request);
  return request;
}

handleRewrittenPackages()

private handleRewrittenPackages(request) {
  let requestingPkg = this.packageCache.ownerOfFile(request.fromFile);
  if (!requestingPkg) {
    return request;
  }
  let packageName = getPackageName(request.specifier);
  if (!packageName) {
    // relative request
    return request;
  }

  let targetPkg;
  if (packageName !== requestingPkg.name) {
    // non-relative, non-self request, so check if it aims at a rewritten addon
    try {
      targetPkg = this.packageCache.resolve(packageName, requestingPkg);
    } catch (err) {
      if (err.code !== 'MODULE_NOT_FOUND') {
        throw err;
      }
    }
  }

  let originalRequestingPkg = this.packageCache.original(requestingPkg);
  let originalTargetPkg = targetPkg ? this.packageCache.original(targetPkg) : undefined;

  if (targetPkg && originalTargetPkg !== targetPkg) {
    // in this case it doesn't matter whether or not the requesting package
    // was moved. RewrittenPackageCache.resolve already took care of finding
    // the right target, and we redirect the request so it will look inside
    // that target.
    return logTransition(
      'request targets a moved package',
      request,
      this.resolveWithinMovedPackage(request, targetPkg)
    );
  } else if (originalRequestingPkg !== requestingPkg) {
    if (targetPkg) {
      // in this case, the requesting package is moved but its destination is
      // not, so we need to rehome the request back to the original location.
      return logTransition(
        'outbound request from moved package',
        request,
        request
          // setting meta here because if this fails, we want the fallback
          // logic to revert our rehome and continue from the *moved* package.
          .withMeta({ originalFromFile: request.fromFile })
          .rehome(resolve(originalRequestingPkg.root, 'package.json'))
      );
    } else {
      // requesting package was moved and we failed to find its target. We
      // can't let that accidentally succeed in the defaultResolve because we
      // could escape the moved package system.
      return logTransition('missing outbound request from moved package', request, request.notFound());
    }
  }

  return request;
}

tiny code

private handleRewrittenPackages(request) {
  let requestingPkg = this.packageCache.ownerOfFile(request.fromFile);
  if (!requestingPkg) {
    return request;
  }
  let packageName = getPackageName(request.specifier);
  if (!packageName) {
    // relative request
    return request;
  }

  let targetPkg;
  if (packageName !== requestingPkg.name) {
    // non-relative, non-self request, so check if it aims at a rewritten addon
    try {
      targetPkg = this.packageCache.resolve(packageName, requestingPkg);
    } catch (err) {
      if (err.code !== 'MODULE_NOT_FOUND') {
        throw err;
      }
    }
  }
  ...
}

Targeting Rewritten

private handleRewrittenPackages(request) {
  let requestingPkg, packageName, targetPkg; // see previous slides

  let originalRequestingPkg = this.packageCache.original(requestingPkg);
  let originalTargetPkg = targetPkg ? this.packageCache.original(targetPkg) : undefined;

  if (targetPkg && originalTargetPkg !== targetPkg) {
    // in this case it doesn't matter whether or not the requesting package
    // was moved. RewrittenPackageCache.resolve already took care of finding
    // the right target, and we redirect the request so it will look inside
    // that target.
    return logTransition(
      'request targets a moved package',
      request,
      this.resolveWithinMovedPackage(request, targetPkg)
    );
  }

  ...
}

private handleRewrittenPackages(request) {
  let requestingPkg, packageName, targetPkg; // see previous slides
  let originalRequestingPkg, originalTargetPkg; // see previous slides

  if (originalRequestingPkg !== requestingPkg) {
    if (targetPkg) {
      // in this case, the requesting package is moved but its destination is
      // not, so we need to rehome the request back to the original location.
      return logTransition(
        'outbound request from moved package',
        request,
        request
          // setting meta here because if this fails, we want the fallback
          // logic to revert our rehome and continue from the *moved* package.
          .withMeta({ originalFromFile: request.fromFile })
          .rehome(resolve(originalRequestingPkg.root, 'package.json'))
      );
    } else {
      // requesting package was moved and we failed to find its target. We
      // can't let that accidentally succeed in the defaultResolve because we
      // could escape the moved package system.
      return logTransition('missing outbound request from moved package', request, request.notFound());
    }
  }

  return request;
}

yea

Ember's journey to build with Vite