Ember.js: Octane Tracking Issue

@MelSumner We should track the build pipeline improvements in https://github.com/embroider-build/embroider as well.

@melsumner https://broccoli.build and https://github.com/broccolijs/broccolijs.github.io for the new broccoli site and docs

Tracked properties RFC can be checked off and link updated.

We talked about auditing what gets included in the default app blueprint. See related issues:

1. https://github.com/ember-cli/ember-cli/issues/6294
2. https://github.com/ember-cli/ember-cli/issues/7760

FWIW, @tomdale that seems quite orthogonal to the Octane Edition to me (not saying we shouldn't be more careful and have better checks/balances, just that its not related to octane at all)...

its not related to octane at all

My reasoning for bringing this up recently is that a default blueprint that supports multiple programming models (i.e., a future default octane blueprint) may include extra cruft that a pure "classic" app or pure "octane" app doesn't need at all.

If we can validate that this is not a concern, I agree that this isn't very closely related to octane

imo, the octane blueprint, https://github.com/ember-cli/ember-octane-blueprint should be the _ideal_ brand new / shiny app. I don't think the old programming model should be involved in the blueprint. :-

@MelSumner - I think we need to get some MU related things here in this checklist (I don't spot any, but AFAICT MU is still considered part of the octane feature set...).

It's already been called Octane layout instead of MU layout ... and the more I think about it the more it makes sense!

@MelSumner - I think we need to get some MU related things here in this checklist (I don't spot any, but AFAICT MU is still considered part of the octane feature set...).

@rwjblue we linked to the MU quest issue in the first section- "Finish What We Started" - is there more that you think we should track?

Regarding ember-cli-create I put this issue together: ember-cli/ember-cli#8343. Depending on how much of the embroider spec will be implemented as part of octane (= _publication_ format), the issue I linked is mainly speaking about the _authoring_ format which can be complementary to the publishing format.

Personally, I wouldn't see ember-cli-create as part of octane while the authoring format _could_ be (which basically sets the foundation for ember-cli-create).

Let me know, if that would make a good addition or better postpone it to post-octane release or how I can help with that.

octane blueprint > move addon to ember-cli org can be checked off :)

Update, here's a quest issue for tracking the Angle Brackets conversion in the guides https://github.com/ember-learn/guides-source/issues/139

The Remove jQuery RFC can be checked off! ✅
I also created a tracking issue, which we can link to maybe: https://github.com/emberjs/ember.js/issues/17476

User story around feature flags and optional features, as it pertains to the octane blueprint

As a workshop instructor, I need to know the default values for various optional/feature flags in the octane blueprint, in order to understand concretely what my students will get when they run ember new, and build material around ember new that remains valid over a significant period of time.

FYI - I just published @ember/render-modifiers 1.0.0 with support back to Ember 2.12 (by way of ember-modifier-manager-polyfill). There is still a bit of work to do (need tons more documentation), but its a good start...

@MelSumner I will work on the Native JS Classes blueprints.

Has anyone put thought into what should happen for https://github.com/ember-cli/ember-new-output in the Classic+Octane world?

The output in that repo will match the output of ember new, which according to our current plans will change to octane blueprint “when it’s ready”.

It looks like module unification is missing from the "Practical Implementation of Roadmap RFC" section.

It looks like module unification is missing from the "Practical Implementation of Roadmap RFC" section.

I believe that Template Imports are the major piece that hasn't shipped yet, so that's the bit that we're tracking in this issue. Does that help, @michaelrkn ?

@MelSumner Got it, thanks!

Hey everybody, the implementation of the "Remove jQuery" RFC is mostly done (at least as far as the first Ember 3.x stage is concerned, see https://github.com/emberjs/ember.js/issues/17476). What's still open and blocking the (default, non-octane) blueprints to switch to no jQuery by default is the built-in ability of ember-data to work with fetch instead of $.ajax (without having to apply the ember-data patch mixin), see the WIP PR: https://github.com/emberjs/data/pull/5386.

Just to let you know... maybe this should be addressed at one of the next core team meetings, to help bring this over the finish line?

a couple things related to ember-cli that I would like to be added to the list:

• addons need some hooks for installing custom types, for example

moduleConfig.collections = Object.assign(moduleConfig.collections, {
  // ember-simple-auth
  authenticators: {
    types: ['authenticator'],
    defaultType: 'authenticator'
  }
});

(the above, courtesy of @sly7-7 :D )
and

moduleConfig.types = Object.assign(moduleConfig.types, {
  // ember-intl
  'ember-intl@adapter': { definitiveCollection: 'main' },
  'ember-intl@translation': { definitiveCollection: 'main' },
  translation: { definitiveCollection: 'main' },
  formats: { definitiveCollection: 'main' },
  cldr: { definitiveCollection: 'main' },
  'util:intl': { definitiveCollection: 'utils' },
  'intl:util': { definitiveCollection: 'utils' },

  // ember-gestures
  'ember-gesture': { definitiveCollection: 'main' },
});

and then the other thing also related to ember-cli is supporting multiple dummy apps.
So far we have some design proposals here:

• https://github.com/ember-cli/ember-cli/pull/8158 (me)
• https://github.com/ember-cli/ember-cli/pull/8416 (@ppcano )

Also, not sure how to track this, but with @miguelcobain 's ember-paper library, I'd like to coordinate with getting the octane setup process super simple (currently it's not simple to use ember-paper in octane apps)

• https://github.com/miguelcobain/ember-paper/issues/883
  /cc @ppcano (you have some stake here as well)

seems like it mostly has to do with there styles get exposed to the host app. idk if there is something simple we can do so that existing style addons can "just work", or if we're going to make all the style addons add an octane / isModuleUnification condition?

@NullVoxPopuli

• the lack of hooks should be filed as a bug (as detailed as possible) (and we can add the octane label to it)
• we don't intend to track specific addons here (this issue is trying to stay focused on tracking the items listed in the roadmap RFC), but maybe we can figure out a way to share an "upgrade your addon" guide? Maybe we could convince @miguelcobain to write one for the emberjs.com blog. ;)

Hey everybody, the implementation of the "Remove jQuery" RFC is mostly done (at least as far as the first Ember 3.x stage is concerned, see #17476). What's still open and blocking the (default, non-octane) blueprints to switch to no jQuery by default is the built-in ability of ember-data to work with fetch instead of $.ajax (without having to apply the ember-data patch mixin), see the WIP PR: emberjs/data#5386.

Just to let you know... maybe this should be addressed at one of the next core team meetings, to help bring this over the finish line?

@dgeb / @igorT can you help with this blocker?

@MelSumner Yup, brought this up at the ED meeting, we are gonna follow up and refactor the ember-fetch PR https://github.com/emberjs/data/pull/5386

@MelSumner

Update blueprints for each object type to use native JS classes has been merged at #17621. Initially, the blueprints will generate Native Classes only when using the octane blueprints.

@tomdale, @MelSumner, @rwjblue

Template Imports ( Working Draft )

https://github.com/crashco/ember-template-component-import/issues/10

FYI, the Component Templates Co-locations RFC is not on this tracking issue yet. :)

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

@Panman8201 correct- it's outside of the scope for Octane. :)

I think this need to bee updated with ember octane 3.15+ release :)

Since we've shipped Octane, going to close this issue.