├── .gitignore ├── teams ├── cli.md ├── data.md ├── learning.md ├── steering.md ├── framework.md └── typescript.md ├── stages ├── closed.md ├── accepted.md ├── exploring.md ├── proposed.md ├── released.md ├── recommended.md ├── discontinued.md └── ready-for-release.md ├── images ├── npm_test.png ├── website_1.png ├── ember_test.png ├── survey_results.png ├── 457-dasherization.jpg ├── website_4-button_ui.png ├── website_6_nav_alt.png ├── website_7_pointer.png ├── 457-autocomplete-problem.gif ├── 457-when-to-use-curlies.jpg ├── EmberJS_Homepage_Outline.pdf ├── survey_results_analysis.pdf ├── website_3_url_examples.png ├── website_5_scrolled_nav.png └── website_2_header_dropdown.png ├── .github ├── doc-assets │ └── advance-rfc.png ├── workflows │ ├── ci.yml │ ├── generate-rfc-frontmatter-json.yml │ ├── label-opened-new-rfc-prs.yml │ ├── trigger-opening-advancement-pr.yml │ └── advance-rfc.yml ├── actions │ ├── setup-rfcs-tooling │ │ └── action.yml │ └── find-added-or-modified-rfcs │ │ └── action.yml ├── PULL_REQUEST_TEMPLATE │ ├── advance-to-released.md │ ├── advance-to-ready-for-release.md │ └── advance-to-recommended.md └── pull_request_template.md ├── CODE_OF_CONDUCT.md ├── text ├── 0889-deprecate-ember-error.md ├── 0092-blueprint-remove-old-files.md ├── 0114-add-template-lint-addon.md ├── 0194-deprecate-custom-event-manager.md ├── 1117-deprecate-classic-classes.md ├── 1114-deprecate-ember-array.md ├── 0020-sri-default.md ├── 1116-deprecate-mixins.md ├── 0743-ember-data-deprecate-legacy-imports.md ├── 0690-deprecate-attrs-in-templates.md ├── 0011-improved-cp-syntax.md ├── 0029-addon-black-and-whitelist-for-apps.md ├── 1112-deprecate-proxy.md ├── 0750-deprecate-ember-assign.md ├── 0794-ember-data-schema-definition-service-simplify.md ├── 0742-ember-data-deprecate-helper-functions.md ├── 0237-deprecation-ember-map.md ├── 0105-addons-optionalDependencies.md ├── 0318-array-helper.md ├── 0999-make-hash-built-in.md ├── 1000-make-array-built-in.md ├── 0324-deprecate-component-isvisible.md ├── 0136-contains-to-includes.md ├── 0421-deprecate-application-controller-props.md ├── 0918-deprecate-travis-ci-support.md ├── 0121-remove-ember-cli-eslint.md ├── 0738-ember-data-deprecate-model-reopen.md ├── 0631-refresh-method-for-router-service.md ├── 0086-firefox-in-ci.md ├── 0181-deprecate-ember-data-initializers.md ├── 1055-vanilla-prettier-setup-in-blueprints.md ├── 0340-deprecate-ember-merge.md ├── 0326-ember-data-filter-deprecation.md ├── 0096-enable-yarn-usage.md ├── 0186-track-unique-history-location-state.md ├── 0741-ember-data-deprecate-model-static-field-access-without-lookup.md ├── 0012-help-json-output.md ├── 0101-ember-data-friendly-errors.md ├── 0752-inject-service.md ├── 0801-deprecate-blacklist-and-whitelist-build-options.md ├── 0050-cli-production-code-stripping.md ├── 0003-cli-ember-doctor.md ├── 0706-deprecate-ember-global.md ├── 0028-app-import-output-file.md ├── 0790-deprecate-ember-data-ajax.md ├── 1026-ember-data-deprecate-store-extends-ember-object.md ├── 0001-transform-attribute-meta-parameter.md ├── 0091-weakmap.md ├── 0272-deprecation-native-function-prototype-extensions.md ├── 0491-deprecate-disconnect-outlet.md ├── 0329-deprecated-ember-evented-in-ember-data.md ├── 0463-record-data-state.md ├── 0139-isHtmlSafe.md ├── 0702-eslint-plugin-qunit.md ├── 0645-add-ember-page-title-addon.md ├── 0796-ember-data-deprecate-rsvp.md ├── 0392-deprecate-component-manager-string-lookup.md ├── 0449-deprecate-partials.md ├── 0521-find-by-identifier.md ├── 0639-replace-blacklist-whitelist.md ├── 0522-default-serializers-and-adapters.md └── 0003-block-params.md ├── deprecation-template.md └── 0000-template.md /.gitignore: -------------------------------------------------------------------------------- 1 | book/ 2 | src/ 3 | -------------------------------------------------------------------------------- /teams/cli.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: CLI 3 | --- 4 | -------------------------------------------------------------------------------- /teams/data.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: Data 3 | --- 4 | -------------------------------------------------------------------------------- /teams/learning.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: Learning 3 | --- 4 | -------------------------------------------------------------------------------- /teams/steering.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: Steering 3 | --- 4 | -------------------------------------------------------------------------------- /teams/framework.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: Framework 3 | --- 4 | -------------------------------------------------------------------------------- /teams/typescript.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: TypeScript 3 | --- 4 | -------------------------------------------------------------------------------- /stages/closed.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: Closed 3 | order: 10 4 | --- 5 | -------------------------------------------------------------------------------- /stages/accepted.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: Accepted 3 | order: 5 4 | --- 5 | -------------------------------------------------------------------------------- /stages/exploring.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: Exploring 3 | order: 1 4 | --- 5 | -------------------------------------------------------------------------------- /stages/proposed.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: Proposed 3 | order: 0 4 | --- 5 | -------------------------------------------------------------------------------- /stages/released.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: Released 3 | order: 7 4 | --- 5 | -------------------------------------------------------------------------------- /stages/recommended.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: Recommended 3 | order: 8 4 | --- 5 | -------------------------------------------------------------------------------- /stages/discontinued.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: Discontinued 3 | order: 11 4 | --- 5 | -------------------------------------------------------------------------------- /images/npm_test.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/emberjs/rfcs/HEAD/images/npm_test.png -------------------------------------------------------------------------------- /images/website_1.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/emberjs/rfcs/HEAD/images/website_1.png -------------------------------------------------------------------------------- /stages/ready-for-release.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: Ready For Release 3 | order: 6 4 | --- 5 | -------------------------------------------------------------------------------- /images/ember_test.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/emberjs/rfcs/HEAD/images/ember_test.png -------------------------------------------------------------------------------- /images/survey_results.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/emberjs/rfcs/HEAD/images/survey_results.png -------------------------------------------------------------------------------- /images/457-dasherization.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/emberjs/rfcs/HEAD/images/457-dasherization.jpg -------------------------------------------------------------------------------- /images/website_4-button_ui.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/emberjs/rfcs/HEAD/images/website_4-button_ui.png -------------------------------------------------------------------------------- /images/website_6_nav_alt.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/emberjs/rfcs/HEAD/images/website_6_nav_alt.png -------------------------------------------------------------------------------- /images/website_7_pointer.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/emberjs/rfcs/HEAD/images/website_7_pointer.png -------------------------------------------------------------------------------- /.github/doc-assets/advance-rfc.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/emberjs/rfcs/HEAD/.github/doc-assets/advance-rfc.png -------------------------------------------------------------------------------- /images/457-autocomplete-problem.gif: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/emberjs/rfcs/HEAD/images/457-autocomplete-problem.gif -------------------------------------------------------------------------------- /images/457-when-to-use-curlies.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/emberjs/rfcs/HEAD/images/457-when-to-use-curlies.jpg -------------------------------------------------------------------------------- /images/EmberJS_Homepage_Outline.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/emberjs/rfcs/HEAD/images/EmberJS_Homepage_Outline.pdf -------------------------------------------------------------------------------- /images/survey_results_analysis.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/emberjs/rfcs/HEAD/images/survey_results_analysis.pdf -------------------------------------------------------------------------------- /images/website_3_url_examples.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/emberjs/rfcs/HEAD/images/website_3_url_examples.png -------------------------------------------------------------------------------- /images/website_5_scrolled_nav.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/emberjs/rfcs/HEAD/images/website_5_scrolled_nav.png -------------------------------------------------------------------------------- /images/website_2_header_dropdown.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/emberjs/rfcs/HEAD/images/website_2_header_dropdown.png -------------------------------------------------------------------------------- /CODE_OF_CONDUCT.md: -------------------------------------------------------------------------------- 1 | The Ember team and community are committed to everyone having a safe and inclusive experience. 2 | 3 | **Our Community Guidelines / Code of Conduct can be found here**: 4 | 5 | http://emberjs.com/guidelines/ 6 | 7 | For a history of updates, see the page history here: 8 | 9 | https://github.com/emberjs/website/commits/master/source/guidelines.html.erb 10 | -------------------------------------------------------------------------------- /.github/workflows/ci.yml: -------------------------------------------------------------------------------- 1 | name: CI 2 | 3 | on: 4 | push: 5 | branches: [master, main] 6 | pull_request: {} 7 | 8 | jobs: 9 | lint-frontmatter: 10 | runs-on: ubuntu-latest 11 | steps: 12 | - uses: actions/checkout@v3 13 | 14 | - name: Setup RFCs tooling 15 | uses: ./.github/actions/setup-rfcs-tooling 16 | 17 | - name: Lint the frontmatter of all RFCs 18 | run: node ./rfcs-tooling/scripts/lint-rfc-frontmatter.mjs text/*.md 19 | -------------------------------------------------------------------------------- /.github/actions/setup-rfcs-tooling/action.yml: -------------------------------------------------------------------------------- 1 | name: Setup RFCs Tooling 2 | description: 'Setup RFCs Tooling' 3 | 4 | runs: 5 | using: "composite" 6 | steps: 7 | - name: Checkout tools repo 8 | uses: actions/checkout@v3 9 | with: 10 | repository: emberjs/rfcs-tooling 11 | path: rfcs-tooling 12 | ref: 'v3.0.0' 13 | 14 | - uses: actions/setup-node@v3 15 | with: 16 | node-version: 16 17 | 18 | - run: yarn install 19 | shell: bash 20 | working-directory: rfcs-tooling 21 | -------------------------------------------------------------------------------- /.github/workflows/generate-rfc-frontmatter-json.yml: -------------------------------------------------------------------------------- 1 | name: Generate a JSON file of all frontmatter 2 | 3 | on: 4 | push: 5 | branches: [ main, master ] 6 | paths: 7 | - 'text/*.md' 8 | 9 | jobs: 10 | generate-rfc-frontmatter-data-artifact: 11 | name: 'Generate a JSON file of RFC status' 12 | runs-on: ubuntu-latest 13 | steps: 14 | - uses: actions/checkout@v3 15 | 16 | - name: Setup RFCs tooling 17 | uses: ./.github/actions/setup-rfcs-tooling 18 | 19 | - name: Generate frontmatter data file 20 | run: | 21 | node rfcs-tooling/scripts/list-frontmatter.mjs text/*.md > rfc-data.json 22 | 23 | - uses: actions/upload-artifact@v4 24 | with: 25 | name: rfc-data 26 | path: rfc-data.json 27 | if-no-files-found: error 28 | overwrite: true 29 | -------------------------------------------------------------------------------- /.github/workflows/label-opened-new-rfc-prs.yml: -------------------------------------------------------------------------------- 1 | name: Label newly opened RFC PRs 2 | 3 | on: 4 | pull_request_target: # This workflow has permissions on the repo, do NOT run code from PRs in this workflow. See https://securitylab.github.com/research/github-actions-preventing-pwn-requests/ 5 | types: [opened] 6 | paths: 7 | - 'text/*.md' 8 | 9 | jobs: 10 | label-pr: 11 | runs-on: ubuntu-latest 12 | steps: 13 | - uses: actions/checkout@v3 14 | with: 15 | ref: ${{ github.event.pull_request.head.sha }} 16 | fetch-depth: 0 17 | persist-credentials: false 18 | 19 | - name: RFCs Added or Changed 20 | id: rfcs 21 | uses: ./.github/actions/find-added-or-modified-rfcs 22 | 23 | - uses: actions-ecosystem/action-add-labels@v1 24 | if: steps.rfcs.outputs.added-rfcs-count > 0 25 | with: 26 | labels: S-Proposed 27 | -------------------------------------------------------------------------------- /text/0889-deprecate-ember-error.md: -------------------------------------------------------------------------------- 1 | --- 2 | stage: recommended 3 | start-date: 2022-12-15T00:00:00.000Z 4 | release-date: 2023-01-12T00:00:00.000Z 5 | release-versions: 6 | ember-source: v4.10.0 7 | teams: 8 | - framework 9 | - typescript 10 | prs: 11 | accepted: 'https://github.com/emberjs/rfcs/pull/889' 12 | released: 'https://github.com/emberjs/rfcs/pull/895' 13 | recommended: 'https://github.com/emberjs/rfcs/pull/899' 14 | project-link: 15 | --- 16 | 17 | # Deprecate @ember/error 18 | 19 | ## Summary 20 | 21 | The @ember/error package is just a re-export of the native Error and is therefore unnecessary. 22 | 23 | ## Motivation 24 | 25 | Removal of unnecessary code keeps the codebase cleaner and simplifies developer burden. 26 | 27 | ## Transition Path 28 | 29 | There is no use case for this anymore. A simple codemod can convert current uses to the native Error class. 30 | 31 | ## How We Teach This 32 | 33 | Remove @ember/error from docs. 34 | 35 | ## Drawbacks 36 | 37 | You'll have to run a codemod to resolve existing usage. However, this is trivial and will actually simplify user code. 38 | 39 | ## Alternatives 40 | 41 | None. 42 | 43 | ## Unresolved questions 44 | 45 | None. 46 | -------------------------------------------------------------------------------- /.github/actions/find-added-or-modified-rfcs/action.yml: -------------------------------------------------------------------------------- 1 | name: Find added or modified RFCs 2 | description: 'Find added or modified RFC' 3 | 4 | # Any workflow using this action requires using actions/checkout with a fetch-depth: 0 5 | 6 | inputs: 7 | base-sha: 8 | description: 'Base SHA' 9 | required: false 10 | sha: 11 | description: 'SHA' 12 | required: false 13 | 14 | outputs: 15 | modified-rfc: 16 | description: "The path of the RFC that was added or modified" 17 | value: ${{ steps.modified-rfc.outputs.path }} 18 | modified-rfcs-count: 19 | description: "The count of how many RFCs were added or modified" 20 | value: ${{ steps.rfcs.outputs.all_changed_files_count }} 21 | added-rfcs-count: 22 | description: "The count of how many RFCs that were added" 23 | value: ${{ steps.rfcs.outputs.added_files_count }} 24 | 25 | runs: 26 | using: "composite" 27 | steps: 28 | - name: Find added or modified RFCs 29 | id: rfcs 30 | uses: tj-actions/changed-files@v39 31 | with: 32 | files: text 33 | json: true 34 | 35 | - name: Find modified or added RFC info 36 | id: modified-rfc 37 | shell: bash 38 | run: | 39 | changed_file=`echo "${{ steps.rfcs.outputs.all_changed_files }}" | jq '.[0]'` 40 | echo "path=$changed_file" >> $GITHUB_OUTPUT 41 | -------------------------------------------------------------------------------- /text/0092-blueprint-remove-old-files.md: -------------------------------------------------------------------------------- 1 | --- 2 | stage: accepted # FIXME: This may be a further stage 3 | start-date: 2016-12-17T00:00:00.000Z 4 | release-date: # FIXME 5 | release-versions: # FIXME 6 | teams: 7 | - cli 8 | prs: 9 | accepted: https://github.com/ember-cli/rfcs/pull/92 10 | project-link: 11 | --- 12 | 13 | # Summary 14 | 15 | Give blueprint generators the ability to clean up old files. 16 | 17 | # Motivation 18 | 19 | We want to eliminate the noise of having old files laying after updating 20 | ember-cli using `ember init`. 21 | 22 | # Detailed design 23 | 24 | We'd like an API for blueprints to delete files instead of only 25 | create. It would be essentially syntactic sugar for removing the file yourself 26 | in an `afterInstall` hook. It would be a returned array on the blueprint's `index.js`. 27 | 28 | ```js 29 | // ember-cli/bluprints/blah/index.js 30 | module.exports = { 31 | // ... 32 | 33 | get oldFilesToRemove() { 34 | return [ 35 | 'brocfile.js', 36 | 'LICENSE.MD', 37 | 'testem.json' 38 | ]; 39 | } 40 | }; 41 | ``` 42 | 43 | # How We Teach This 44 | 45 | The guides could use this addition in the blueprints section, but I envision it 46 | being used by mostly power users. 47 | 48 | A changelog entry should be sufficient to teach this. 49 | 50 | # Drawbacks 51 | 52 | The only reason to not do this is to hold out for a large blueprint reworking. 53 | We would be locked into this API. 54 | 55 | # Alternatives 56 | 57 | The key name can be bikeshed. I chose `oldFilesToRemove` to be verbose and 58 | explicit, but it can be changed. 59 | -------------------------------------------------------------------------------- /text/0114-add-template-lint-addon.md: -------------------------------------------------------------------------------- 1 | --- 2 | stage: discontinued # FIXME: Is this correct? We don't quite do what is specified here 3 | start-date: 2018-01-04T00:00:00.000Z 4 | release-date: # FIXME 5 | release-versions: # FIXME 6 | teams: 7 | - cli 8 | prs: 9 | accepted: https://github.com/ember-cli/rfcs/pull/114 10 | project-link: 11 | --- 12 | 13 | # Summary 14 | 15 | Add https://github.com/rwjblue/ember-cli-template-lint as a default addon for the app and addon blueprints using the recommended rules. 16 | 17 | # Motivation 18 | 19 | Linting and security in templates would help not only individual developers write better apps with better accessibility and security, but would also help teams to be on the same page and stick to a handful of standards. 20 | 21 | # Detailed design 22 | 23 | 1. Move ember-cli-template-lint to the ember-cli org (better for contributing and getting work off one person, @rwjblue) 24 | 2. Add the dependency to the app blueprint here: https://github.com/ember-cli/ember-cli/blob/master/blueprints/app/files/package.json#L19 25 | 3. Also add it to the addon blueprint, like the eslint addon here: https://github.com/ember-cli/ember-cli/blob/master/blueprints/addon/index.js#L66 26 | 27 | # How We Teach This 28 | 29 | The same way that we teach ESLint being on by default. 30 | 31 | # Drawbacks 32 | 33 | - More chatter in the terminal. 34 | - An additional dependency. 35 | - Recommended rules might not be good for everyone.. but that same issue probably exists with ESLint. 36 | 37 | # Alternatives 38 | 39 | Do nothing and have people write sub par template code. 40 | 41 | # Unresolved questions 42 | 43 | None 44 | -------------------------------------------------------------------------------- /text/0194-deprecate-custom-event-manager.md: -------------------------------------------------------------------------------- 1 | --- 2 | stage: recommended 3 | start-date: 2016-12-24T00:00:00.000Z 4 | release-date: 2018-02-13T00:00:00.000Z 5 | release-versions: 6 | ember-source: v3.0.0 7 | 8 | teams: 9 | - framework 10 | prs: 11 | accepted: https://github.com/emberjs/rfcs/pull/194 12 | project-link: 13 | meta: 14 | ember-issue: https://github.com/emberjs/ember.js/issues/14754 15 | --- 16 | 17 | # Summary 18 | 19 | Support for component `eventManger`s is a seldom used feature and should 20 | be deprecated. 21 | 22 | # Motivation 23 | 24 | We should strive to simplify the Ember API and source code where possible. As 25 | the custom `eventManager` feature is rarely used in apps, we should deprecate 26 | it. 27 | 28 | # Detailed design 29 | 30 | We'll introduce a deprecation warning which will be displayed when a component 31 | defines an `eventManager` property or when `canDispatchToEventManager` is set to 32 | true on `EventDispatcher`. The warning will have a target version of `3.0`. 33 | 34 | If required, we can create an addon which extends the `EventDispatcher` allowing 35 | for opt-in custom `eventManager`s in Ember apps. 36 | 37 | # How We Teach This 38 | 39 | As this is a seldom used feature, we can simply note the deprecation in a 40 | future release blog post. 41 | 42 | # Drawbacks 43 | 44 | This adds a little more churn for apps that rely on this feature. 45 | 46 | # Alternatives 47 | 48 | This feature was [recently made pay-as-you-go](https://github.com/emberjs/ember.js/pull/14756), 49 | so the immediate performance concerns have been addressed. We could decide to 50 | leave this in the framework as an opt-in feature. 51 | -------------------------------------------------------------------------------- /.github/workflows/trigger-opening-advancement-pr.yml: -------------------------------------------------------------------------------- 1 | name: Trigger the opening of a PR to advance an RFC to the next stage 2 | 3 | on: 4 | workflow_dispatch: 5 | inputs: 6 | rfc-path: 7 | type: string 8 | required: true 9 | description: Path to the RFC to open PR for advancement to the next stage 10 | 11 | jobs: 12 | gather-rfc-info: 13 | name: 'Gather RFC info' 14 | runs-on: ubuntu-latest 15 | outputs: 16 | new-stage: ${{ steps.new-stage.outputs.value }} 17 | rfc-number: ${{ steps.rfc.outputs.rfc-number }} 18 | 19 | steps: 20 | - uses: actions/checkout@v3 21 | 22 | - name: Setup RFCs tooling 23 | uses: ./.github/actions/setup-rfcs-tooling 24 | 25 | - name: Find RFC Number 26 | id: rfc 27 | run: | 28 | rfc=${{ inputs.rfc-path }} 29 | rfc_number="${rfc//[!0-9]/}" 30 | echo "RFC Number: $rfc_number" 31 | echo "rfc-number=$rfc_number" >> $GITHUB_OUTPUT 32 | 33 | - name: Find new stage 34 | id: new-stage 35 | run: | 36 | new_stage=`node rfcs-tooling/scripts/find-next-stage.mjs ${{ inputs.rfc-path }}` 37 | echo "New Stage: $new_stage" 38 | echo "value=$new_stage" >> $GITHUB_OUTPUT 39 | 40 | 41 | advance-rfc: 42 | uses: ./.github/workflows/open-advancement-pr.yml 43 | needs: [ gather-rfc-info ] 44 | if: needs.gather-rfc-info.outputs.new-stage 45 | with: 46 | rfc-path: ${{ inputs.rfc-path }} 47 | rfc-number: ${{ needs.gather-rfc-info.outputs.rfc-number }} 48 | new-stage: ${{ needs.gather-rfc-info.outputs.new-stage }} 49 | secrets: 50 | personal-access-token: ${{ secrets.PERSONAL_ACCESS_TOKEN }} 51 | -------------------------------------------------------------------------------- /text/1117-deprecate-classic-classes.md: -------------------------------------------------------------------------------- 1 | --- 2 | stage: accepted 3 | start-date: 2025-06-20T00:00:00.000Z 4 | release-date: 5 | release-versions: 6 | teams: # delete teams that aren't relevant 7 | - cli 8 | - data 9 | - framework 10 | - learning 11 | - steering 12 | - typescript 13 | prs: 14 | accepted: https://github.com/emberjs/rfcs/pull/1117 15 | project-link: 16 | --- 17 | 18 | # Deprecate Classic Classes 19 | 20 | ## Summary 21 | 22 | Deprecate the Classic Class system. 23 | 24 | ## Motivation 25 | 26 | For quite a while now, Ember has recommended the use of Native Classes over the Classic Class 27 | system. The one remaining sticking point has been Mixins. If we 28 | [Deprecate Mixins](https://github.com/emberjs/rfcs/pull/1116), then we can deprecate the Classic Class system. 29 | 30 | ## Transition Path 31 | 32 | All uses of Classic Classes should be converted to Native Classes. Anything that cannot be converted will be deprecated first, such as [Mixins](https://github.com/emberjs/rfcs/pull/1116) and the [`observer` helper function](https://github.com/emberjs/rfcs/pull/1115). 33 | 34 | The `@classic` decorator (and any other APIs or patterns used to enable classic class interop) will also be deprecated as part of this transition. All code should migrate to native class syntax and patterns. 35 | 36 | ## Exploration 37 | 38 | To validate this deprecation, I've tried removing all of the Classic Class system in this PR: 39 | https://github.com/emberjs/ember.js/pull/20923 40 | 41 | ## How We Teach This 42 | 43 | We should remove all references from the guides. 44 | 45 | ## Drawbacks 46 | 47 | Other than it being a lot of work, there are no drawbacks. 48 | 49 | ## Alternatives 50 | 51 | None 52 | 53 | ## Unresolved questions 54 | 55 | Should we keep `EmberObject` around as a home for some utility methods and sugar or remove it entirely? -------------------------------------------------------------------------------- /text/1114-deprecate-ember-array.md: -------------------------------------------------------------------------------- 1 | --- 2 | stage: accepted 3 | start-date: 2025-06-13T00:00:00.000Z 4 | release-date: 5 | release-versions: 6 | teams: # delete teams that aren't relevant 7 | - cli 8 | - data 9 | - framework 10 | - learning 11 | - typescript 12 | prs: 13 | accepted: https://github.com/emberjs/rfcs/pull/1114 14 | project-link: 15 | --- 16 | 17 | # Deprecating Ember Array 18 | 19 | ## Summary 20 | 21 | Deprecate `Ember.Array`, `Ember.MutableArray`, `Ember.ArrayProxy`, `Ember.NativeArray`, `Ember.A`, 22 | `Ember.Enumerable` and Array computed macros. 23 | 24 | ## Motivation 25 | 26 | Now that Ember has a proper tracking system and the availability of `tracked-built-ins` we no longer 27 | need our own custom arrays. In addition, much of the internal implementation relies upon Mixins which 28 | we also hope to deprecate in the future. 29 | 30 | ## Transition Path 31 | 32 | All uses of custom Arrays should be replaced with native Arrays and `tracked-built-ins`. 33 | Additionally, computed macros should be updated to use tracked getters. 34 | 35 | Given how estabished these patterns are, we probably want to provide an addon that brings 36 | back at least some of the functionality to aid migration. 37 | 38 | ## Exploration 39 | 40 | To validate this deprecation, I've tried removing EmberArray in this PR: 41 | https://github.com/emberjs/ember.js/pull/20921 42 | 43 | ## How We Teach This 44 | 45 | We should replace any references in the guides with native arrays or `TrackedArray`. 46 | 47 | ## Drawbacks 48 | 49 | This functionality is old and very well established, removing it will not be without pain 50 | to many users. 51 | 52 | ## Alternatives 53 | 54 | Deprecate just `Ember.A`: #864 55 | 56 | ## Unresolved questions 57 | 58 | None 59 | 60 | ## Notes 61 | 62 | This overlaps with #1112 which also seeks to deprecate `Ember.ArrayProxy`. 63 | -------------------------------------------------------------------------------- /text/0020-sri-default.md: -------------------------------------------------------------------------------- 1 | --- 2 | stage: recommended 3 | start-date: 2015-07-10T00:00:00.000Z 4 | release-date: 2015-07-29T00:00:00.000Z 5 | release-versions: 6 | ember-cli: v1.13.5 7 | 8 | teams: 9 | - cli 10 | prs: 11 | accepted: https://github.com/ember-cli/rfcs/pull/20 12 | project-link: 13 | --- 14 | 15 | # Summary 16 | 17 | Enable [Subresource Integrity [SRI]](http://www.w3.org/TR/SRI/) checks by default. 18 | 19 | # Motivation 20 | 21 | To promote the use of SRI in Ember apps as a safe default. Applications should be built with integrity attributes when it is safe to do so. (Unfortunately the main advantage won't be met by default, however confirming one attribute will) 22 | 23 | This solves having poisoned CDN content: [An introduction to JavaScript-based DDoS](https://blog.cloudflare.com/an-introduction-to-javascript-based-ddos/) 24 | 25 | 26 | # Detailed design 27 | 28 | Install [ember-cli-sri](https://www.npmjs.com/package/ember-cli-sri) by default. 29 | 30 | - Applications with relative paths will get SRI. 31 | - Applications with `SRI.crossorigin` will get SRI on `fingerprint.prepend` assets 32 | - Applications with `fingerprint.prepend` and `origin` specified and matching get a `SRI.crossorigin` of anonymous on `fingerprint.prepend` assets 33 | 34 | By default development environments wont run SRI for performance reasons. 35 | 36 | Further explanation available in: [ember-cli-sri](https://www.npmjs.com/package/ember-cli-sri) 37 | 38 | # Drawbacks 39 | 40 | - SRI won't always be on for sites with prepend due to SRI requiring CORS. 41 | - CORS requirement adds a barrier to entry to some users. 42 | - Broken SRI attrs would break the application. 43 | 44 | # Alternatives 45 | 46 | No other alternatives appear suitable. 47 | 48 | # Unresolved questions 49 | 50 | - Adding origin attribute to add a safe same-origin check that doesn't need CORS. 51 | - Could users be warned until they explicitly set `SRI.enabled = false` or `SRI.crossorigin = `? 52 | -------------------------------------------------------------------------------- /text/1116-deprecate-mixins.md: -------------------------------------------------------------------------------- 1 | --- 2 | stage: accepted 3 | start-date: 2025-06-20T00:00:00.000Z 4 | release-date: 5 | release-versions: 6 | teams: # delete teams that aren't relevant 7 | - cli 8 | - framework 9 | - learning 10 | - typescript 11 | prs: 12 | accepted: https://github.com/emberjs/rfcs/pull/1116 13 | project-link: 14 | --- 15 | 16 | # Deprecating Mixin Support 17 | 18 | ## Summary 19 | 20 | Deprecate all Mixin support. 21 | 22 | ## Motivation 23 | 24 | For a while now, Ember has not recommended the use of Mixins. We should actually fully 25 | deprecate this. 26 | 27 | ## Transition Path 28 | 29 | All existing public Ember mixins will be deprecated: 30 | 31 | - [Ember.Mixin](https://github.com/emberjs/rfcs/pull/1111) (from `@ember/object/mixin`) 32 | - [Ember.PromiseProxyMixin](https://github.com/emberjs/rfcs/pull/1112) (from `@ember/object/promise-proxy-mixin`) 33 | - [Ember.Comparable](https://github.com/emberjs/rfcs/pull/1113) (from `@ember/object/comparable`) 34 | - [Ember.Enumerable](https://github.com/emberjs/rfcs/pull/1114) (from `@ember/object/enumerable`) 35 | - [Ember.Observable](https://github.com/emberjs/rfcs/pull/1115) (from `@ember/object/observable`) 36 | 37 | For users that still want mixin-like functionality, we should recommend class 38 | decorators. If this feels less ergonimic that we would desire, we can consider 39 | providing an addon that adds some sugar around this. 40 | 41 | ## Exploration 42 | 43 | To validate this deprecation, I've tried removing all Mixins in this PR: https://github.com/emberjs/ember.js/pull/20923 44 | 45 | ## How We Teach This 46 | 47 | We should remove all references from the guides and provide a [deprecation guide](https://github.com/ember-learn/deprecation-app/pull/1408). 48 | 49 | ## Drawbacks 50 | 51 | Some users probably rely on this functionality. However, it's almost certainly 52 | something that we don't need to keep in Ember itself. 53 | 54 | ## Alternatives 55 | 56 | None 57 | 58 | ## Unresolved questions 59 | 60 | None -------------------------------------------------------------------------------- /text/0743-ember-data-deprecate-legacy-imports.md: -------------------------------------------------------------------------------- 1 | --- 2 | stage: recommended 3 | start-date: 2021-04-23T00:00:00.000Z 4 | release-date: 2023-09-18T00:00:00.000Z 5 | release-versions: 6 | ember-data: v5.3.0 7 | teams: 8 | - data 9 | prs: 10 | accepted: 'https://github.com/emberjs/rfcs/pull/743' 11 | ready-for-release: 'https://github.com/emberjs/rfcs/pull/947' 12 | released: 'https://github.com/emberjs/rfcs/pull/969' 13 | recommended: 'https://github.com/emberjs/rfcs/pull/979' 14 | --- 15 | 16 | # EmberData | Deprecate Legacy Imports 17 | 18 | ## Summary 19 | 20 | Deprecates `import DS from "ember-data";` and individual imports within the `ember-data` 21 | package in favor of the imports provided by [RFC#395 packages](https://github.com/emberjs/rfcs/blob/master/text/0395-ember-data-packages.md) 22 | 23 | ## Motivation 24 | 25 | These imports are just a legacy remnant we no longer need. 26 | 27 | ## Detailed design 28 | 29 | Lint rules and a codemod already exist to migrate users to using packages, and have been 30 | available now for over a year. 31 | 32 | The ember-data-packages plugin for ember-cli-babel would be updated so that users would 33 | receive a deprecation when importing from the legacy paths. If required for legacy global 34 | or DS import a runtime deprecation would be added as well. 35 | 36 | To resolve, users would need only to run the codemod to convert to using packages. 37 | 38 | The deprecation would target `5.0` and would become `enabled` no-sooner than `4.1` (although 39 | it may be made `available` before then). 40 | 41 | ## How we teach this 42 | 43 | Users have already been encouraged to migrate, documentation has already been updated to reflect 44 | the package based imports, and lint rules and codemods already exist. Deprecating and removal at 45 | this point is just a formality as the last stage of fading out the old world. 46 | 47 | ## Drawbacks 48 | 49 | Someone somewhere probably is doing something bad. 50 | 51 | ## Alternatives 52 | 53 | Leave them to waste away. 54 | -------------------------------------------------------------------------------- /text/0690-deprecate-attrs-in-templates.md: -------------------------------------------------------------------------------- 1 | --- 2 | stage: recommended 3 | start-date: 2020-12-22T00:00:00.000Z 4 | release-date: 2021-03-22T00:00:00.000Z 5 | release-versions: 6 | ember-source: v3.26.0 7 | 8 | teams: 9 | - framework 10 | prs: 11 | accepted: https://github.com/emberjs/rfcs/pull/690 12 | project-link: 13 | --- 14 | 15 | # Deprecate using `{{attrs}}` in templates 16 | 17 | ## Summary 18 | 19 | The `{{attrs}}` object in templates is an alternative way for users to reference 20 | named arguments directly in a template. 21 | 22 | ```hbs 23 | {{attrs.foo}} 24 | 25 | {{! is equivalent to }} 26 | {{@foo}} 27 | ``` 28 | 29 | It was a legacy API that existed prior to named arguments being introduced in 30 | Ember, and has continued to be supported via a template transform for some time. 31 | This RFC proposes that we deprecate this functionality in favor of directly 32 | using named arguments. 33 | 34 | ## Motivation 35 | 36 | The `{{attrs}}` syntax was from a previous iteration of the concepts that 37 | eventually became named argument syntax. Now that named arguments exist in the 38 | framework, and are considered the best practice, there is no reason to continue 39 | supporting this syntax. 40 | 41 | ## Transition Path 42 | 43 | Users who currently rely on referencing `{{attrs}}` can convert their references 44 | to named arguments. This should be highly codemoddable, and we will attempt to 45 | make a codemod to help out with the transition. 46 | 47 | ## How We Teach This 48 | 49 | ### Deprecation Guide 50 | 51 | The `{{attrs}}` object was an alternative way to reference named arguments in 52 | templates that was introduced prior to named arguments syntax being finalized. 53 | References to properties on `{{attrs}}` can be converted directly to named 54 | argument syntax. 55 | 56 | Before: 57 | 58 | ```hbs 59 | {{attrs.foo}} 60 | {{this.attrs.foo.bar}} 61 | {{deeply (nested attrs.foobar.baz)}} 62 | ``` 63 | 64 | After: 65 | 66 | ```hbs 67 | {{@foo}} 68 | {{@foo.bar}} 69 | {{deeply (nested @foobar.baz)}} 70 | ``` 71 | 72 | ## Drawbacks 73 | 74 | - None 75 | -------------------------------------------------------------------------------- /.github/PULL_REQUEST_TEMPLATE/advance-to-released.md: -------------------------------------------------------------------------------- 1 | # Advance #__RFC_NUMBER__ to the [Released Stage](https://github.com/emberjs/rfcs#released) 2 | 3 | ## [Rendered](__RFC_RENDERED_URL__) 4 | 5 | ## Summary 6 | 7 | This pull request is advancing the RFC to the [Released Stage](https://github.com/emberjs/rfcs#released). 8 | 9 | - PR to Accepted Stage: #__RFC_NUMBER__ 10 | - [PR to Ready For Release Stage](__READY_FOR_RELEASE_PR__) 11 | 12 | Upon merging this PR, automation will open a draft PR for this RFC to move to the [Recommended Stage](https://github.com/emberjs/rfcs#recommended). 13 | 14 |
15 | Released Stage Summary 16 | 17 | The work is published. If it is codebase-related work, it is in a stable version of the relevant package(s). If there are any critical deviations from the original RFC, they are briefly noted at the top of the RFC. 18 | 19 | If the work for an RFC is spread across multiple releases of Ember or other packages, the RFC is considered to be in the Released stage when all features are available in stable releases and those packages and versions are noted in the RFC frontmatter. 20 | 21 | Ember's RFC process can be used for process and work plans that are not about code. Some examples include Roadmap RFCs, changes to the RFC process itself, and changes to learning resources. When such an RFC is a candidate for Released, the work should be shipped as described, and the result should presented to the team with the intent of gathering feedback about whether anything is missing. If there is agreement that the work is complete, the RFC may be marked "Released" and a date is provided instead of a version. 22 | 23 | An RFC is moved into "Released" when the above is verified by consensus of the relevant team(s) via a PR to update the stage. 24 |
25 | 26 | ## Checklist to move to Released 27 | 28 | - [ ] The work is published in stable versions of the relevant package(s), with any feature flags toggled on. 29 | - [ ] Deviations from the original RFC are noted in the RFC 30 | - [ ] Release packages and dates are updated in the RFC frontmatter 31 | -------------------------------------------------------------------------------- /text/0011-improved-cp-syntax.md: -------------------------------------------------------------------------------- 1 | --- 2 | stage: discontinued 3 | start-date: 2014-09-30T00:00:00.000Z 4 | release-date: 2014-10-28T00:00:00.000Z 5 | release-versions: 6 | ember-source: v1.8.0 7 | 8 | teams: 9 | - framework 10 | prs: 11 | accepted: https://github.com/emberjs/rfcs/pull/11 12 | project-link: 13 | meta: 14 | ember-issue: https://github.com/emberjs/ember.js/pull/9527 15 | --- 16 | 17 | # Summary 18 | 19 | Improve computed property syntax 20 | 21 | # Motivation 22 | 23 | Today, the setter variant of CP's is both confusing, and looks scary as sin. 24 | (Too many concepts must be taught and it is too easy to screw it up.) 25 | 26 | # Detailed design 27 | 28 | today: 29 | ------ 30 | 31 | ```js 32 | fullName: Ember.computed('firstName', 'lastName', function(key, value) { 33 | if (arguments.length > 1) { 34 | var names = value.split(' '); 35 | this.setProperties({ 36 | firstName: names[0], 37 | lastName: names[1] 38 | }); 39 | return value; 40 | } 41 | 42 | return this.get('firstName') + ' ' + this.get('lastName'); 43 | }); 44 | ``` 45 | 46 | Tomorrow: 47 | --------- 48 | 49 | ```js 50 | fullName: Ember.computed('firstName', 'lastName', { 51 | get: function(keyName) { 52 | return this.get('firstName') + ' ' + this.get('lastName'); 53 | }, 54 | 55 | set: function(keyName, fullName, oldValue) { 56 | var names = fullName.split(' '); 57 | 58 | this.setProperties({ 59 | firstName: names[0], 60 | lastName: names[1] 61 | }); 62 | 63 | return fullName; 64 | } 65 | }); 66 | ``` 67 | 68 | 69 | Notes: 70 | ------ 71 | 72 | * we should keep `Ember.computed(fn);` as shorthand for getter only 73 | * `get` xor `set` variants would also be possible. 74 | * `{ get() { } }` is es6 syntax for `{ get: function() { } )` 75 | 76 | Migration 77 | --------- 78 | 79 | * 1.x support both, detect new behaviour by testing if the last arg is not null and typeof object 80 | * 1.x+1 deprecate if last arg is a function and its arity is greater than 1 81 | 82 | 83 | # Drawbacks 84 | 85 | N/A 86 | 87 | # Alternatives 88 | 89 | N/A 90 | 91 | # Unresolved questions 92 | 93 | None 94 | -------------------------------------------------------------------------------- /text/0029-addon-black-and-whitelist-for-apps.md: -------------------------------------------------------------------------------- 1 | --- 2 | stage: accepted # FIXME: This may be a further stage or Discontinued since we now have allowlist and blocklist. 3 | start-date: 2015-11-11T00:00:00.000Z 4 | release-date: # FIXME 5 | release-versions: # FIXME 6 | teams: 7 | - cli 8 | prs: 9 | accepted: https://github.com/ember-cli/rfcs/pull/29 10 | project-link: 11 | --- 12 | 13 | # Summary 14 | 15 | It should be possible to white- and/or blacklist addons in `EmberApp`. 16 | 17 | # Motivation 18 | 19 | If there are two (or more) `EmberApp`s, it's very likely that not all applications need all addons. 20 | E.g. if there is a main page application and one application for embeddable widgets, the main page might need all sorts of addons like `ember-modal-dialog` which adds completely useless bytes to widgets javascript and css files for the widgets. Other addons may add useless initializers or other things that have runtime performance penalties for no benefit. 21 | 22 | # Detailed design 23 | 24 | When EmberApp ctor gets passed a blacklist like this 25 | 26 | ```javascript 27 | EmberApp({ 28 | addonBlacklist: ['ember-modal-dialog'] 29 | }); 30 | ``` 31 | 32 | it won't add addons whose `name` matches `ember-modal-dialog` to the list of addons for this app, just as if the addon's `isEnabled()` hook returned `false`. 33 | 34 | C.f. https://github.com/ember-cli/ember-cli/blob/master/lib/broccoli/ember-app.js#L344, this is also were I would add this check. 35 | 36 | Whitelist could work analogously. 37 | 38 | # Drawbacks 39 | 40 | - It adds a bit of API surface while you (possibly) don't care for the multiple app use case of ember-cli. 41 | 42 | - It kinda makes the `name` of an addon public api, so people might change it, not noticing they are breaking people's build (and people might not notice it either). Some addons have names like `Ember CLI ic-ajax` which seems awkward to use as an identifier. 43 | 44 | # Alternatives 45 | 46 | - Add a unified way to enable/disable an addon via normal config 47 | - if that is added one day, the white/blacklist could still be an abstraction for that 48 | 49 | # Unresolved questions 50 | 51 | None. 52 | -------------------------------------------------------------------------------- /text/1112-deprecate-proxy.md: -------------------------------------------------------------------------------- 1 | --- 2 | stage: accepted 3 | start-date: 2025-06-13T00:00:00.000Z 4 | release-date: 5 | release-versions: 6 | teams: # delete teams that aren't relevant 7 | - cli 8 | - data 9 | - framework 10 | - learning 11 | - steering 12 | - typescript 13 | prs: 14 | accepted: https://github.com/emberjs/rfcs/pull/1112 15 | project-link: 16 | --- 17 | 18 | 30 | 31 | # Deprecating Ember Proxies 32 | 33 | ## Summary 34 | 35 | Now that Native Proxy is available in all supported environments, we can deprecate 36 | Ember's custom Proxy handling provided by `ArrayProxy`, `ObjectProxy`, and `PromiseProxyMixin`. 37 | 38 | ## Motivation 39 | 40 | These patterns were introduce to Ember prior to the availability of Native Proxy. Since 41 | Native Proxy is now available in all supported environments, we can deprecate these 42 | patterns in favor of the native Proxy API. 43 | 44 | Additionally, we would like to deprecate Mixins in the future necessitating that we first 45 | deprecate `PromiseProxyMixin`. 46 | 47 | ## Transition Path 48 | 49 | There is no direct migration path for these. Code that relies upon this behavior will have to be rewritten. 50 | 51 | See the deprecation guide (PR'd here: https://github.com/ember-learn/deprecation-app/pull/1405 ) 52 | 53 | ## Exploration 54 | 55 | To validate this deprecation, I've tried removing the assocaited functionality in this PR: 56 | https://github.com/emberjs/ember.js/pull/20918 57 | 58 | ## How We Teach This 59 | 60 | We should remove references to these patterns from the guides. 61 | 62 | ## Drawbacks 63 | 64 | By not providing a direct replacement some users may have difficulty migrating. 65 | 66 | ## Alternatives 67 | 68 | None 69 | 70 | ## Unresolved questions 71 | 72 | None 73 | -------------------------------------------------------------------------------- /text/0750-deprecate-ember-assign.md: -------------------------------------------------------------------------------- 1 | --- 2 | stage: recommended 3 | start-date: 2021-05-26T00:00:00.000Z 4 | release-date: 2021-11-15T00:00:00.000Z 5 | release-versions: 6 | ember-source: v4.0.0 7 | 8 | teams: 9 | - framework 10 | prs: 11 | accepted: https://github.com/emberjs/rfcs/pull/750 12 | project-link: 13 | --- 14 | 15 | 25 | 26 | # Deprecate Ember.assign 27 | 28 | ## Summary 29 | 30 | Now that Ember is dropping support for IE11, we no longer need `Ember.assign` as a polyfill since `Object.assign` 31 | is available in all browsers that Ember v4.x supports ([CanIUse](https://caniuse.com/mdn-javascript_builtins_object_assign), [MDN](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/assign#browser_compatibility)). 32 | 33 | ## Motivation 34 | 35 | The polyfill is no longer necessary, as well as being another Emberism that can be removed. Apps and addons can use `Object.assign` or object destructuring depending on their browser support targets. 36 | 37 | ## Transition Path 38 | 39 | The transition path is relatively simple: apps that use Ember 4.x will replace `Ember.assign` with `Object.assign`, and apps and addons that use or support Ember 3.x can continue to use the polyfill if needed. 40 | 41 | ex: 42 | ``` 43 | import { assign as emberAssign } from '@ember/polyfills'; 44 | 45 | const assign = Object.assign || emberAssign; 46 | ``` 47 | 48 | ## How We Teach This 49 | 50 | A descriptive deprecation message alerting a developer that `Ember.assign` is deprecated and can be replaced with `Object.assign`. 51 | 52 | ## Drawbacks 53 | 54 | The only drawback is replacing the polyfill assign with the native assign, but there is minimal effort to do this. 55 | 56 | ## Alternatives 57 | 58 | Doing nothing. 59 | 60 | ## Unresolved questions 61 | 62 | None. 63 | -------------------------------------------------------------------------------- /text/0794-ember-data-schema-definition-service-simplify.md: -------------------------------------------------------------------------------- 1 | --- 2 | stage: accepted # FIXME: This may be a further stage 3 | start-date: 2022-02-12T00:00:00.000Z 4 | release-date: 5 | release-versions: 6 | teams: 7 | - data 8 | prs: 9 | accepted: https://github.com/emberjs/rfcs/pull/794 10 | project-link: 11 | --- 12 | 13 | # Simplify Schema Definition Service methods in Ember Data 14 | 15 | ## Summary 16 | 17 | This RFC is an amendment to the Custom Model Classes RFC (https://github.com/emberjs/rfcs/pull/487). 18 | Based on implementation feedback, we discovered we could simplify the arguments to 19 | `attributesDefinitionFor` and `relationshipsDefinitionFor` to drop the string argument and always 20 | pass in an object. 21 | 22 | 23 | ## Motivation 24 | 25 | When implementing a schema service, code ends up easier and cleaner if it does not have to deal with 26 | both a raw string and an object. 27 | 28 | ## Detailed design 29 | 30 | The original RFC proposed the following interface: 31 | 32 | ```typescript 33 | interface SchemaDefinitionService { 34 | // Following the existing RD implementation 35 | attributesDefinitionFor(identifier: RecordIdentifier | type: string): AttributesDefinition 36 | 37 | // Following the existing RD implementation 38 | relationshipsDefinitionFor(identifier: RecordIdentifier | type: string): RelationshipsDefinition 39 | doesTypeExist(type: string): boolean 40 | } 41 | ``` 42 | 43 | We can simplify `attributesDefinitionFor` and `relationshipsDefinitionFor` methods to always accept an object. 44 | 45 | ```typescript 46 | interface SchemaDefinitionService { 47 | // Following the existing RD implementation 48 | attributesDefinitionFor(identifier: RecordIdentifier | { type: string }): AttributesDefinition 49 | 50 | // Following the existing RD implementation 51 | relationshipsDefinitionFor(identifier: RecordIdentifier | { type: string }): RelationshipsDefinition 52 | 53 | doesTypeExist(type: string): boolean 54 | } 55 | ``` 56 | 57 | ## How we teach this 58 | 59 | It simplifies the types passed in, so should be easier to teach. 60 | 61 | 62 | ## Drawbacks 63 | 64 | 65 | ## Alternatives 66 | 67 | Keeping the existing design per the original RFC. 68 | -------------------------------------------------------------------------------- /text/0742-ember-data-deprecate-helper-functions.md: -------------------------------------------------------------------------------- 1 | --- 2 | stage: accepted 3 | start-date: 2021-04-23T00:00:00.000Z 4 | release-date: 5 | release-versions: 6 | teams: 7 | - data 8 | prs: 9 | accepted: https://github.com/emberjs/rfcs/pull/742 10 | project-link: 11 | --- 12 | 13 | # EmberData | Deprecate Helper Functions 14 | 15 | ## Summary 16 | 17 | Deprecates the exported util functions `errorsHashToArray` `errorsArrayToHash` 18 | and `normalizeModelName` that were recommended for deprecation by the [RFC#395 packages](https://github.com/emberjs/rfcs/blob/master/text/0395-ember-data-packages.md) 19 | 20 | ## Motivation 21 | 22 | These utils are a legacy remnant of when parts of the codebase were shared with each other 23 | by a `DS` global. Over time their utility has shrunk and today they no longer align with 24 | the direction of [error management](https://github.com/emberjs/rfcs/blob/master/text/0465-record-data-errors.md) or [type constraints](https://github.com/emberjs/rfcs/pull/740). 25 | 26 | ## Detailed design 27 | 28 | Users would receive a build-time deprecation when importing these methods using the paths 29 | specified in [RFC#395 packages](https://github.com/emberjs/rfcs/blob/master/text/0395-ember-data-packages.md). 30 | 31 | They would receive a run-time deprecation when using these methods via the `DS` global. 32 | 33 | The deprecation would target `5.0` and would become `enabled` no-sooner than `4.1` (although 34 | it may be made `available` before then). 35 | 36 | Users making use of these methods can trivially copy them into their own codebase to continue 37 | using them, though we recommend refactoring to a more direct conversion into the expected errors 38 | format. For refactoring `normalizeModelName` we also recommend following [RFC#740 Deprecate Non-Strict Types](https://github.com/emberjs/rfcs/pull/740). 39 | 40 | ## How we teach this 41 | 42 | Generally usage has not been widely observed and these are not methods commonly shown in 43 | examples or docs. We should make sure to audit for usages and remove them if they exist. 44 | 45 | ## Drawbacks 46 | 47 | A trivial amount of churn for users that did utilize them. 48 | 49 | ## Alternatives 50 | 51 | Leave them to waste away. 52 | -------------------------------------------------------------------------------- /text/0237-deprecation-ember-map.md: -------------------------------------------------------------------------------- 1 | --- 2 | stage: recommended 3 | start-date: 2017-07-20T00:00:00.000Z 4 | release-date: 2018-07-16T00:00:00.000Z 5 | release-versions: 6 | ember-source: v3.3.0 7 | 8 | teams: 9 | - framework 10 | prs: 11 | accepted: https://github.com/emberjs/rfcs/pull/237 12 | project-link: 13 | --- 14 | 15 | # Summary 16 | 17 | This RFC proposes the deprecation of the following classes: 18 | 19 | - `Ember.OrderedSet` 20 | - `Ember.Map` 21 | - `Ember.MapWithDefault` 22 | 23 | These classes need to be moved to an external addon given they are private classes and unused in Ember.js itself. 24 | 25 | # Motivation 26 | 27 | These classes have not been used in Ember itself for a while now. They have always been private but they are used in a few addons, and in particular Ember Data is using them. 28 | 29 | # Transition Path 30 | 31 | `Ember.Map` and `Ember.MapWithDefault` will be deprecated and not extracted, but not before the fix mentioned in the following paragraph is landed in Ember Data. There is already an addon with `Ember.OrderedSet` extracted ([@ember/ordered-set](https://github.com/emberjs/ember-ordered-set)). 32 | 33 | Ember Data is quite likely the biggest project using these classes. There is already a PR that needs merging before deprecating `Ember.Map` and `Ember.MapWithDefault` https://github.com/emberjs/data/pull/5255. Ember Data still needs to migrate to `@ember/ordered-set` to its relationship logic. 34 | 35 | Once Ember Data is updated to not use the classes from Ember, and that fix is released, the `Ember.Map` and `Ember.MapWithDefault` can be deprecated in Ember itself. 36 | 37 | # How We Teach This 38 | 39 | These classes being private would make this simple than other deprecations. People were not supposed to be using a private API and the few that were, would just need to use a new addon. 40 | 41 | This should not impact many codebases. 42 | 43 | # Drawbacks 44 | 45 | This requires cooperation with Ember Data, the main user of these classes. It would be nice to have moved Ember Data to using the addon before releasing Ember with the deprecation so the average user does not see any deprecation warning. 46 | 47 | # Alternatives 48 | 49 | Other option would be moving these classes to Ember Data itself or leaving things as they are now. 50 | 51 | # Unresolved questions 52 | -------------------------------------------------------------------------------- /text/0105-addons-optionalDependencies.md: -------------------------------------------------------------------------------- 1 | --- 2 | stage: accepted # FIXME: This may be a further stage 3 | start-date: 2017-04-23T00:00:00.000Z 4 | release-date: # FIXME 5 | release-versions: # FIXME 6 | teams: 7 | - cli 8 | prs: 9 | accepted: https://github.com/ember-cli/rfcs/pull/105 10 | project-link: 11 | --- 12 | 13 | # Summary 14 | 15 | It should be possible to specify packages/addons in `optionalDependencies` of the `package.json` of an `ember-cli project`, and ember-cli should scan for packages/addons mentioned in optionalDependencies while processing the build so that such packages/addons could also be included into the consuming application. 16 | 17 | The build need not fail asserting "missing dependency" if any of the dependencies specified in optionalDependencies is missing/absent. 18 | 19 | # Motivation 20 | 21 | In general, the current ember-cli build process will scan for the packages specified in the `dependencies` hash and `devDependencies hash` from the downloaded packages in the node_modules folder, discovers and then includes them into the consuming application. The build is designed to fail if any of the packages specified in these two dependencies hash is missing in the `node_modules` folder. But this procedure may not be sufficient for a variety of cases. 22 | 23 | So there could be an option for the developer to specify packages in optionalDependencies and ember-cli can lookup optionalDependencies while processing the build. The Build need not fail if there is any package specified in optionalDependencies is missing, since it is only optional and moreover may only be required for developmental purposes. This way the developer can have more control over the choice of packages he wishes to use for development and skip for production by giving appropriate commands like `npm install --no-optional`, thereby preventing the installation of packages itself rather than blacklisting in `ember-cli-build.js` which suggests preventing the installed addons sepcifed in the `blacklist` array from being included into the consuming application. 24 | 25 | # Detailed design 26 | We can tweak ember-cli addon/package discovery process to lookup for optionalDependencies as well and if the package is missing, we can make ember-cli proceed the build without terminating. 27 | 28 | # How We Teach This 29 | 30 | This functionality can simply be documented in ember-cli guides to teach. 31 | 32 | # Alternatives 33 | 34 | None. 35 | -------------------------------------------------------------------------------- /text/0318-array-helper.md: -------------------------------------------------------------------------------- 1 | --- 2 | stage: recommended 3 | start-date: 2018-03-24T00:00:00.000Z 4 | release-date: 2019-04-01T00:00:00.000Z 5 | release-versions: 6 | ember-source: v3.9.0 7 | 8 | teams: 9 | - framework 10 | prs: 11 | accepted: https://github.com/emberjs/rfcs/pull/318 12 | project-link: 13 | meta: 14 | tracking: https://github.com/emberjs/rfc-tracking/issues/23 15 | --- 16 | 17 | # `array` helper 18 | 19 | ## Summary 20 | 21 | This RFC proposes to add an `array` template helper for creating arrays in templates. 22 | 23 | The helper would be invoked as `(array arg1 ... argN)` and return the value `[arg1, ..., argN]`. For example, `(array 'a' 'b' 'c')` would return the value `['a', 'b', 'c']`. 24 | 25 | 26 | ## Motivation 27 | 28 | Objects (or hashes) and arrays are the two main data structures in JavaScript. Ember already has a `hash` helper for building objects, so it makes sense to also include an `array` helper for building arrays. 29 | 30 | ## Detailed design 31 | 32 | The design is straightforward and mirrors the design of the `hash` helper. In particular, the important thing to note is that if any of the arguments to the `array` helper change then an entirely new array will be returned, rather than updating the existing array in place. 33 | 34 | The implementation would also mirror the [implementation of the `hash` helper](https://github.com/emberjs/ember.js/blob/ec9f4e5e5f4099a77a73bc5a9aa41916f0d15d6d/packages/ember-glimmer/lib/helpers/hash.ts#L49-L51) and would simply capture the positional arguments instead. 35 | 36 | ## How we teach this 37 | 38 | This helper is not an important part of the programming model and can just be mentioned in the [API docs](https://emberjs.com/api/ember/release/classes/Ember.Templates.helpers) like its sibling the `hash` helper. 39 | 40 | ## Drawbacks 41 | 42 | As usual, adding new helpers increases the surface area of the API and file size but in this case it is justified because the file size change is extremely small and its actually filling an existing hole in the API. 43 | 44 | ## Alternatives 45 | 46 | This helper could be left to addons, and indeed there are addons that include this helper. It's also trivial to generate 47 | your own `array` helper with `ember generate helper array`. Humorously, the default helper blueprint generates a helper that already acts like the `array` helper ;) 48 | 49 | Nevertheless, I believe it's preferable to include this helper in Ember to fill the hole in Ember's API. 50 | -------------------------------------------------------------------------------- /text/0999-make-hash-built-in.md: -------------------------------------------------------------------------------- 1 | --- 2 | stage: accepted 3 | start-date: 2023-12-22T00:00:00.000Z 4 | release-date: # In format YYYY-MM-DDT00:00:00.000Z 5 | release-versions: 6 | teams: # delete teams that aren't relevant 7 | - framework 8 | - learning 9 | - typescript 10 | prs: 11 | accepted: https://github.com/emberjs/rfcs/pull/0999 12 | project-link: 13 | suite: 14 | --- 15 | 16 | 29 | 30 | # Make `(hash)` a built in helper 31 | 32 | ## Summary 33 | 34 | Today, when using gjs/gts/`