Crates.io: Tracking issue for upgrading to Ember Octane

Created on 2 Aug 2019  路  11Comments  路  Source: rust-lang/crates.io

Hi,

I'm an experienced Ember.js dev, a budding Rust dev, and would like to offer my services to help upgrade the crates.io frontend code to the more modern techniques and paradigms available in what will soon be released as Ember Octane.

This would include changes along the lines of:

  • [x] Updating to the latest ember-source, ember-cli-babel, ember-data, and other relevant packages.
  • [x] Moving to native JavaScript class syntax with decorators. This applies to components, routes, controllers, services, adapters, models etc.
  • [x] Moving to native getters instead of using get() and this.get().
  • Updating templates to use:

    • [x] outer HTML semantics

    • [x] angle bracket syntax

    • [x] named args and

    • [x] the {{on}} and {{fn}} modifiers instead of {{action}}

  • [x] Refactoring away any remaining uses of observers and jQuery.
  • [x] Adding ember-template-lint to enforce modern template style such as this. prefixes.

All of the above are possible as of the current stable Ember 3.11 release, and there would be a few more items added once Ember Octane is completed. Specifically: tracked properties and completing the move to Octane components that would already be well-advanced following the above work.

I've managed similar code transitions on a large Ember codebase before and am comfortable with what's involved. The work breaks down easily into a series of separate PRs at whatever level of granularity is desired.

Please let me know if there's any appetite for this upgrade, if anyone's already working on something similar or is keen to be involved, and then we can go from there.

Thanks!

A-frontend C-tracking-issue

Most helpful comment

There are plans to migrate away from Ember while redesigning crates.io at the same time

I don't think there is consensus among the team on what this would like like and how to land the changes incrementally. Even if we had an outline of a clear path forward, I expect that we will be committed to maintaining the frontend for at least another year or 2 until the migration was complete. Therefore, I think there is a lot of value in ensuring the frontend dependencies are kept up to date and that current Ember best practices are followed.

All 11 comments

Hi @richard-viney! A couple of Ember people have sporadically helped modernize the codebase and the changes were welcome once discussed with the crates team. A currently related effort is the Enable Fastboot, which required updating several dependencies.
I would like to quickly say that there are some specific challenges in the codebase that we should address first to lay the groundwork for the rest of the upgrades. I've linked to this issue in the team's Discord and would like to help plan out the work to maximize shipping without disrupting the website :)

There are plans to migrate away from Ember while redesigning crates.io at the same time, see e.g. this comment. For this reason, I'm not sure we want to migrate to a new version of Ember at this point, unless this migration would solve the problems that prompted the decision to migrate away from Ember (the details of which I am not aware of).

There are plans to migrate away from Ember while redesigning crates.io at the same time

I don't think there is consensus among the team on what this would like like and how to land the changes incrementally. Even if we had an outline of a clear path forward, I expect that we will be committed to maintaining the frontend for at least another year or 2 until the migration was complete. Therefore, I think there is a lot of value in ensuring the frontend dependencies are kept up to date and that current Ember best practices are followed.

OK, thanks for the info & insight everyone.

One consideration is that many modernisation opportunities in Ember Octane can be done independently of other structural refactoring that may be needed in the codebase. Keeping the two separate is likely to make life easier. E.g. a component can be updated to use ES6 classes and decorators without actually altering its logic or structure, and there are codemods being worked on that aim to do this in a largely automated fashion.

@locks Do you have a link to the crates.io team's Discord so I can read through the discussion there?

@richard-viney https://discord.gg/zVc7xf is the channel. I am mainly working on https://github.com/rust-lang/crates.io/pull/1715 so far and in the channel as @kzys as well.

@richard-viney hey :) did you join the discord?

@locks Yep I'm on Discord as richard-nz. I see #1715 and also #1817 have been merged recently - great! I've got availability to work on these. upgrades over the next month if it's on the cards.

Hi folks! I worked on the original Ember crates.io app and currently am one of the maintainers of Ember. As @richard-viney said, it's probably worth upgrading to Octane separately from any other structural changes.

I'm interested in pitching in here -- a lot of my current work is evaluating Octane against real-world applications (beyond the app I work on at work) and crates.io would be a great addition to that effort.

Should I hop in on Discord?

Hi @wycats! Hopping in Discord to help us out would be great! Us Rust folks really have no idea what we're doing 馃惗 so we'd love your guidance.

Pinging this thread that I've added Ember to the agenda for this week. If you're able to attend, the meeting is in the Discord channel at 2019-10-31 20:00 UTC (agenda). It's the third item, so we'll probably start discussing it about 10 minutes into the meeting.

As I understand it, there is general agreement on the modern style and code lints that could be applied. There may however be details and planning to work though to update dependencies, in particular for ember-data.

If you're not able to make the meeting, feel free to reach out async via the Discord channel as well.

The minimal dependencies changes for Fastboot have been landed on master, and Fastboot itself can be disabled by un-setting USE_FASTBOOT. The whole effort is tracked by #1811.

So, I hope that you may not have big package.json conflicts from Fastboot-related changes!

Was this page helpful?
0 / 5 - 0 ratings

Related issues

carols10cents picture carols10cents  路  5Comments

sunjay picture sunjay  路  3Comments

dtolnay picture dtolnay  路  6Comments

kejadlen picture kejadlen  路  4Comments

mleonhard picture mleonhard  路  5Comments