From 3f5e630c83be7feaa9c74fd0de1092b5a41fc0e7 Mon Sep 17 00:00:00 2001 From: cibernox Date: Tue, 10 Jan 2017 09:08:20 +0000 Subject: [PATCH 01/12] Standarize targets in configuration --- active/0000-standarise-targets.md | 115 ++++++++++++++++++++++++++++++ 1 file changed, 115 insertions(+) create mode 100644 active/0000-standarise-targets.md diff --git a/active/0000-standarise-targets.md b/active/0000-standarise-targets.md new file mode 100644 index 0000000..24ffdf1 --- /dev/null +++ b/active/0000-standarise-targets.md @@ -0,0 +1,115 @@ +- Start Date: 2017-01-03 +- RFC PR: (leave this empty) +- Ember CLI Issue: (leave this empty) + +# Summary + +This RFC proposes the introdution of a official convention to specify the targets of an +application. + +### Motivation + +Javascript and the platforms it runs on are moving targets. NodeJS and browsers release new +versions every few weeks. Browsers auto update and each update bings new language features +and APIs. + +Developers need an easy way to express intention that abstracts them from the everchanging +landscape of versions and feature matrices, so this RFC proposes to introduce a universal +configuration option to let developers express they intended targets + +This configuration should be easily available to addons, but this RFC doesn't impose +any mandatory behaviour on addons. All addons that want to get customize their behaviour +depending on the target platforms will have a single source of truth to get that +information but it's up to them to do it. + +The advantage of having a single source of truth for the targets compared to having several +configurations, each one with its own `targets` is mostly for better ergonomics and across-the-board +consitency. + +Addons that would benefit from this conventions are `babel-preset-env`, `autoprefixer`, +`stylelint` and `eslint` (vía `eslint-plugin-compat`), but not only those. Even Ember itself could, +once converted into an addon, take advantage of that to avoid polyfilling or even taking +advantage of some DOM API (`node.classList`?) deep in Glimmer's internals. + +### Detailed implementation + +What seems to be the most popular tool and the state of the art on this is the [browserlist](https://github.com/ai/browserslist) +npm package. + +That package is the one behind `babel-preset-env`, `autoprefixer` and others, and uses the data from +[Can I Use](http://caniuse.com/) for knowing the JS, CSS and other APIs available on every browser. + +The syntax is also pretty flexible as it allows all sort of complex queries like `Firefox >= 20`, +`>2.5% in CA` (browsers with a market share over 2.5% in Canada) and logical combinations. + +Using this syntax would allow us to integrate easily with other tools. + +Example usage: + +```js +var app = new EmberApp(defaults, { + targets: ['>2%', 'last 3 iOS versions', 'not ie <= 8'] +}); +``` + +This configuration must be made available to addons. It's up to the addons to use it. +I suggest to make it available in `this.project.targets` + +```js +module.exports = { + name: 'ember-data', + + included(app) { + this._super.included.apply(this, arguments); + + console.log(app.targets); // ['>2%', 'last 3 iOS versions', 'not ie <= 8'] + } +}; +``` + +# How We Teach This + +This is a new concept in Ember CLI, so guides will have to be updated to explain this +concept. The good part is that this new concept can help enforcing with tools a task were +traditionally enforced only with peer reviews. + +To ease the transition Ember CLI can also, in the absence of a specific value provided by the user, +default to a predefined matrix of browsers that matches the browsers officially supported by the framework. + +# Drawbacks + +While this RFC standarizes a concept that will open the door to better and more comprehensive tooling, +it makes us choose one syntax (the one used by [browserlist](https://github.com/ai/browserslist)) over +any other perhaps supperior choice that may exist or appear in the future. + +# Alternatives + +Let every addon that wants to deal with targets to have a `targets`-like option in its configuration +instead of standarizing a single configuration option, which effectively leaves things as they are +right now. + +Example: + +``` +var app = new EmberApp(defaults, { + 'ember-cli-autoprefixer': { + browers: ... + }, + 'ember-cli-babel': { + targets: ... + }, + 'ember-cli-eslint': { + engines: ... + }, + ... +}); +``` + +# Unresolved questions + +As of today, seems that the database used by [browserlist](https://github.com/ai/browserslist) does +not cover Node.js versions. +With Ember apps running in fastboot this might be a gap in functionality that we have to +fill in a different way, although since this RFC just specifies the syntax, not the tool +that understands it, it is possible that specifying `targets: ['>2%', 'node 4']` becomes +supported and this wouldn't contradict this RFC. \ No newline at end of file From 1a36ee648967e2d555ea27262a3ac6f5fb606d64 Mon Sep 17 00:00:00 2001 From: cibernox Date: Tue, 10 Jan 2017 14:09:33 +0000 Subject: [PATCH 02/12] Add entry about how to support node --- active/0000-standarise-targets.md | 55 ++++++++++++++++++++++++++----- 1 file changed, 46 insertions(+), 9 deletions(-) diff --git a/active/0000-standarise-targets.md b/active/0000-standarise-targets.md index 24ffdf1..3ea8d9a 100644 --- a/active/0000-standarise-targets.md +++ b/active/0000-standarise-targets.md @@ -33,6 +33,9 @@ advantage of some DOM API (`node.classList`?) deep in Glimmer's internals. ### Detailed implementation + +### Browser support + What seems to be the most popular tool and the state of the art on this is the [browserlist](https://github.com/ai/browserslist) npm package. @@ -48,12 +51,14 @@ Example usage: ```js var app = new EmberApp(defaults, { - targets: ['>2%', 'last 3 iOS versions', 'not ie <= 8'] + targets: { + browsers: ['>2%', 'last 3 iOS versions', 'not ie <= 8'] + } }); ``` This configuration must be made available to addons. It's up to the addons to use it. -I suggest to make it available in `this.project.targets` +I suggest to make it available in `app.targets` ```js module.exports = { @@ -62,11 +67,47 @@ module.exports = { included(app) { this._super.included.apply(this, arguments); - console.log(app.targets); // ['>2%', 'last 3 iOS versions', 'not ie <= 8'] + console.log(app.targets.browsers); // ['>2%', 'last 3 iOS versions', 'not ie <= 8'] } }; ``` +### Node support + +In addition to browsers, Ember apps can run in node using ember-fastboot. If that is the +case, we need to cover node as a target, but it deserves a different entry on `targets.node`. + +The sintax for for this configuration option is even simpler, since apps will only run in a single +version of node and developers are in control of it, so the only thing users must specify is the +minimum supported version of node. + +Example usage: + +```js +var app = new EmberApp(defaults, { + targets: { + browsers: ['>2%', 'last 3 iOS versions', 'not ie <= 8'], + node: "6" + } +}); +``` + +This configuration is also available to addons in `app.targets.node`; + +```js +module.exports = { + name: 'ember-data', + + included(app) { + this._super.included.apply(this, arguments); + + console.log(app.targets.node); // "6" + } +}; +``` + +If this property is not provided, addons can assume that this app does not target node. + # How We Teach This This is a new concept in Ember CLI, so guides will have to be updated to explain this @@ -107,9 +148,5 @@ var app = new EmberApp(defaults, { # Unresolved questions -As of today, seems that the database used by [browserlist](https://github.com/ai/browserslist) does -not cover Node.js versions. -With Ember apps running in fastboot this might be a gap in functionality that we have to -fill in a different way, although since this RFC just specifies the syntax, not the tool -that understands it, it is possible that specifying `targets: ['>2%', 'node 4']` becomes -supported and this wouldn't contradict this RFC. \ No newline at end of file +The proposed syntax for node only supports a single version of node. Is it reasonable to +make this property an array of versions? P.e. `["4.4", "6", "7"]` From 73eb8f390c3dba431636d934e21ca3dd389319e9 Mon Sep 17 00:00:00 2001 From: Mario Gintili Date: Wed, 11 Jan 2017 11:16:42 +0000 Subject: [PATCH 03/12] Fix typo --- active/0000-standarise-targets.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/active/0000-standarise-targets.md b/active/0000-standarise-targets.md index 3ea8d9a..d791673 100644 --- a/active/0000-standarise-targets.md +++ b/active/0000-standarise-targets.md @@ -4,7 +4,7 @@ # Summary -This RFC proposes the introdution of a official convention to specify the targets of an +This RFC proposes the introduction of a official convention to specify the targets of an application. ### Motivation From 5a3dbabe0b740c6a17377bcf7a2ae57c1f960543 Mon Sep 17 00:00:00 2001 From: cibernox Date: Wed, 11 Jan 2017 15:07:20 +0000 Subject: [PATCH 04/12] Fix typos --- active/0000-standarise-targets.md | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/active/0000-standarise-targets.md b/active/0000-standarise-targets.md index d791673..f35e5e0 100644 --- a/active/0000-standarise-targets.md +++ b/active/0000-standarise-targets.md @@ -10,21 +10,21 @@ application. ### Motivation Javascript and the platforms it runs on are moving targets. NodeJS and browsers release new -versions every few weeks. Browsers auto update and each update bings new language features +versions every few weeks. Browsers auto update and each update brings new language features and APIs. -Developers need an easy way to express intention that abstracts them from the everchanging +Developers need an easy way to express intention that abstracts them from the ever-changing landscape of versions and feature matrices, so this RFC proposes to introduce a universal configuration option to let developers express they intended targets This configuration should be easily available to addons, but this RFC doesn't impose -any mandatory behaviour on addons. All addons that want to get customize their behaviour +any mandatory behavior on addons. All addons that want to get customize their behavior depending on the target platforms will have a single source of truth to get that information but it's up to them to do it. The advantage of having a single source of truth for the targets compared to having several configurations, each one with its own `targets` is mostly for better ergonomics and across-the-board -consitency. +consistency. Addons that would benefit from this conventions are `babel-preset-env`, `autoprefixer`, `stylelint` and `eslint` (vía `eslint-plugin-compat`), but not only those. Even Ember itself could, @@ -77,7 +77,7 @@ module.exports = { In addition to browsers, Ember apps can run in node using ember-fastboot. If that is the case, we need to cover node as a target, but it deserves a different entry on `targets.node`. -The sintax for for this configuration option is even simpler, since apps will only run in a single +The syntax for for this configuration option is even simpler, since apps will only run in a single version of node and developers are in control of it, so the only thing users must specify is the minimum supported version of node. @@ -119,14 +119,14 @@ default to a predefined matrix of browsers that matches the browsers officially # Drawbacks -While this RFC standarizes a concept that will open the door to better and more comprehensive tooling, +While this RFC standardizes a concept that will open the door to better and more comprehensive tooling, it makes us choose one syntax (the one used by [browserlist](https://github.com/ai/browserslist)) over -any other perhaps supperior choice that may exist or appear in the future. +any other perhaps superior choice that may exist or appear in the future. # Alternatives Let every addon that wants to deal with targets to have a `targets`-like option in its configuration -instead of standarizing a single configuration option, which effectively leaves things as they are +instead of standardizing a single configuration option, which effectively leaves things as they are right now. Example: @@ -134,7 +134,7 @@ Example: ``` var app = new EmberApp(defaults, { 'ember-cli-autoprefixer': { - browers: ... + browsers: ... }, 'ember-cli-babel': { targets: ... From 05a4cf5b1a10a9e0dd942c6d65b0e480c65ff0e2 Mon Sep 17 00:00:00 2001 From: cibernox Date: Fri, 27 Jan 2017 15:54:34 +0000 Subject: [PATCH 05/12] Improve some sentences --- active/0000-standarise-targets.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/active/0000-standarise-targets.md b/active/0000-standarise-targets.md index f35e5e0..375f890 100644 --- a/active/0000-standarise-targets.md +++ b/active/0000-standarise-targets.md @@ -18,12 +18,12 @@ landscape of versions and feature matrices, so this RFC proposes to introduce a configuration option to let developers express they intended targets This configuration should be easily available to addons, but this RFC doesn't impose -any mandatory behavior on addons. All addons that want to get customize their behavior +any mandatory behavior on addons. All addons that want to customize their behavior depending on the target platforms will have a single source of truth to get that -information but it's up to them to do it. +information but it's up to them how to use it. -The advantage of having a single source of truth for the targets compared to having several -configurations, each one with its own `targets` is mostly for better ergonomics and across-the-board +The advantage of having a single source of truth for the targets compared to configure this +on a per-addon basis like we do today is mostly for better ergonomics and across-the-board consistency. Addons that would benefit from this conventions are `babel-preset-env`, `autoprefixer`, From e2b5779f1958a1550485a4633eda6c108e710a5f Mon Sep 17 00:00:00 2001 From: cibernox Date: Thu, 2 Feb 2017 23:02:31 +0000 Subject: [PATCH 06/12] Some improvements --- active/0000-standarise-targets.md | 42 ++++--------------------------- 1 file changed, 5 insertions(+), 37 deletions(-) diff --git a/active/0000-standarise-targets.md b/active/0000-standarise-targets.md index 375f890..b973e1f 100644 --- a/active/0000-standarise-targets.md +++ b/active/0000-standarise-targets.md @@ -7,7 +7,7 @@ This RFC proposes the introduction of a official convention to specify the targets of an application. -### Motivation +# Motivation Javascript and the platforms it runs on are moving targets. NodeJS and browsers release new versions every few weeks. Browsers auto update and each update brings new language features @@ -15,7 +15,7 @@ and APIs. Developers need an easy way to express intention that abstracts them from the ever-changing landscape of versions and feature matrices, so this RFC proposes to introduce a universal -configuration option to let developers express they intended targets +configuration option to let developers express their intended targets This configuration should be easily available to addons, but this RFC doesn't impose any mandatory behavior on addons. All addons that want to customize their behavior @@ -31,8 +31,7 @@ Addons that would benefit from this conventions are `babel-preset-env`, `autopre once converted into an addon, take advantage of that to avoid polyfilling or even taking advantage of some DOM API (`node.classList`?) deep in Glimmer's internals. -### Detailed implementation - +# Detailed design ### Browser support @@ -74,39 +73,8 @@ module.exports = { ### Node support -In addition to browsers, Ember apps can run in node using ember-fastboot. If that is the -case, we need to cover node as a target, but it deserves a different entry on `targets.node`. - -The syntax for for this configuration option is even simpler, since apps will only run in a single -version of node and developers are in control of it, so the only thing users must specify is the -minimum supported version of node. - -Example usage: - -```js -var app = new EmberApp(defaults, { - targets: { - browsers: ['>2%', 'last 3 iOS versions', 'not ie <= 8'], - node: "6" - } -}); -``` - -This configuration is also available to addons in `app.targets.node`; - -```js -module.exports = { - name: 'ember-data', - - included(app) { - this._super.included.apply(this, arguments); - - console.log(app.targets.node); // "6" - } -}; -``` - -If this property is not provided, addons can assume that this app does not target node. +In addition to browsers, Ember apps can run in node using ember-fastboot, but this is already covered implicitly +by the `engines` property in the package.json of the app (or the host app in the case of engines), so no new syntax needed. # How We Teach This From de5447ffb657e5a8284ed7ab9dfed9cc60432916 Mon Sep 17 00:00:00 2001 From: cibernox Date: Thu, 2 Feb 2017 23:49:45 +0000 Subject: [PATCH 07/12] Bikesheding how/where this configuration lives --- active/0000-standarise-targets.md | 34 ++++++++++++++++++++----------- 1 file changed, 22 insertions(+), 12 deletions(-) diff --git a/active/0000-standarise-targets.md b/active/0000-standarise-targets.md index b973e1f..626c299 100644 --- a/active/0000-standarise-targets.md +++ b/active/0000-standarise-targets.md @@ -46,18 +46,13 @@ The syntax is also pretty flexible as it allows all sort of complex queries like Using this syntax would allow us to integrate easily with other tools. -Example usage: - -```js -var app = new EmberApp(defaults, { - targets: { - browsers: ['>2%', 'last 3 iOS versions', 'not ie <= 8'] - } -}); -``` +This configuration should be placed in a file that allows javascript execution and exports an object +with the configuration. `.ember-cli` could suffice. A new dedicated file under `/config` could also +be a good option, much like `config/ember-try.js`. This configuration must be made available to addons. It's up to the addons to use it. -I suggest to make it available in `app.targets` +I suggest to make it available in `this.project.targets.browsers`. This getter will return +the specified config or the default matrix of supported browsers. ```js module.exports = { @@ -66,7 +61,7 @@ module.exports = { included(app) { this._super.included.apply(this, arguments); - console.log(app.targets.browsers); // ['>2%', 'last 3 iOS versions', 'not ie <= 8'] + console.log(this.project.targets.browsers); // ['>2%', 'last 3 iOS versions', 'not ie <= 8'] } }; ``` @@ -74,7 +69,22 @@ module.exports = { ### Node support In addition to browsers, Ember apps can run in node using ember-fastboot, but this is already covered implicitly -by the `engines` property in the package.json of the app (or the host app in the case of engines), so no new syntax needed. +by the `engines` property in the package.json of the app (or the host app in the case of engines), so no new syntax needed +for defining the support. + +The minimum supported version of node will be available in `this.project.targets.node`. + +```js +module.exports = { + name: 'ember-data', + + included(app) { + this._super.included.apply(this, arguments); + + console.log(this.project.targets.node); // '>= 4' + } +}; +``` # How We Teach This From 62184830c047f4d7784dd7a310003def13d9cdc3 Mon Sep 17 00:00:00 2001 From: cibernox Date: Thu, 2 Feb 2017 23:56:05 +0000 Subject: [PATCH 08/12] Better wording --- active/0000-standarise-targets.md | 18 +++++++++++------- 1 file changed, 11 insertions(+), 7 deletions(-) diff --git a/active/0000-standarise-targets.md b/active/0000-standarise-targets.md index 626c299..e73e578 100644 --- a/active/0000-standarise-targets.md +++ b/active/0000-standarise-targets.md @@ -33,8 +33,6 @@ advantage of some DOM API (`node.classList`?) deep in Glimmer's internals. # Detailed design -### Browser support - What seems to be the most popular tool and the state of the art on this is the [browserlist](https://github.com/ai/browserslist) npm package. @@ -46,13 +44,19 @@ The syntax is also pretty flexible as it allows all sort of complex queries like Using this syntax would allow us to integrate easily with other tools. -This configuration should be placed in a file that allows javascript execution and exports an object -with the configuration. `.ember-cli` could suffice. A new dedicated file under `/config` could also +This configuration must be made available to addons. It's up to the addons to use honor it. + +### Browser support + +The configution of target browsers must in a file that allows javascript execution and exports an object +with the configuration. Putting the configuration in a file with javascript execution is important because +allows us to have different config in development and production without having to different keys per +environment or any other environment variable. + +One option is the `.ember-cli` file. A new dedicated file under `/config` could also be a good option, much like `config/ember-try.js`. -This configuration must be made available to addons. It's up to the addons to use it. -I suggest to make it available in `this.project.targets.browsers`. This getter will return -the specified config or the default matrix of supported browsers. +To addons this list of target browsers will be available in `this.project.targets.browsers`. E.g: ```js module.exports = { From 239e7174e4b8196f682e90b64a336fef7962efad Mon Sep 17 00:00:00 2001 From: cibernox Date: Fri, 3 Feb 2017 00:07:04 +0000 Subject: [PATCH 09/12] Mention official support matrix --- active/0000-standarise-targets.md | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/active/0000-standarise-targets.md b/active/0000-standarise-targets.md index e73e578..62ebf78 100644 --- a/active/0000-standarise-targets.md +++ b/active/0000-standarise-targets.md @@ -99,6 +99,12 @@ traditionally enforced only with peer reviews. To ease the transition Ember CLI can also, in the absence of a specific value provided by the user, default to a predefined matrix of browsers that matches the browsers officially supported by the framework. +As of today, the supported browser list for Ember.js, according to the platforms we test in saucelabs, is: + +`['IE9', 'Chrome current', 'Safari current', 'Firefox current']` + +There is no mention to IOS/Android, so this must be validated still. + # Drawbacks While this RFC standardizes a concept that will open the door to better and more comprehensive tooling, From 77f28a95e952a37b8614745bd04c434384d3c703 Mon Sep 17 00:00:00 2001 From: cibernox Date: Fri, 3 Feb 2017 01:13:17 +0000 Subject: [PATCH 10/12] Clarify minimum common denominator --- active/0000-standarise-targets.md | 13 +++++++++++-- 1 file changed, 11 insertions(+), 2 deletions(-) diff --git a/active/0000-standarise-targets.md b/active/0000-standarise-targets.md index 62ebf78..19a51a2 100644 --- a/active/0000-standarise-targets.md +++ b/active/0000-standarise-targets.md @@ -42,9 +42,18 @@ That package is the one behind `babel-preset-env`, `autoprefixer` and others, an The syntax is also pretty flexible as it allows all sort of complex queries like `Firefox >= 20`, `>2.5% in CA` (browsers with a market share over 2.5% in Canada) and logical combinations. -Using this syntax would allow us to integrate easily with other tools. +The way this library works is calculating the minimum common denominator on a per-feature basis. -This configuration must be made available to addons. It's up to the addons to use honor it. +Per example, if the support matrix for an app is `['IE11', 'Firefox latest']` and we have a linter +that warns us when we use an unsupported browser API, it would warn us if we try to use +pointer events (supported in IE11 but not in Firefox), would warn us also when using `fetch` (supported +in firefox but not in IE) and would not warn us when using `MutationObserver` because it is supported by both. + +This library is very powerful and popular, making relatively easy to integrate with a good amount of +tools that use it in little time. + +This configuration must be made available to addons but we it's up to the addon authors to take advantage +of it. ### Browser support From facacb67cff113159d5414a52a9e952ff54f9c14 Mon Sep 17 00:00:00 2001 From: cibernox Date: Fri, 3 Feb 2017 09:32:24 +0000 Subject: [PATCH 11/12] Improve RFC in general --- active/0000-standarise-targets.md | 58 ++++++++++++++++++------------- 1 file changed, 34 insertions(+), 24 deletions(-) diff --git a/active/0000-standarise-targets.md b/active/0000-standarise-targets.md index 19a51a2..a1f8ad2 100644 --- a/active/0000-standarise-targets.md +++ b/active/0000-standarise-targets.md @@ -4,8 +4,8 @@ # Summary -This RFC proposes the introduction of a official convention to specify the targets of an -application. +This RFC proposes the introduction of a official convention to specify the target browsers +and node versions of an application. # Motivation @@ -14,35 +14,38 @@ versions every few weeks. Browsers auto update and each update brings new langua and APIs. Developers need an easy way to express intention that abstracts them from the ever-changing -landscape of versions and feature matrices, so this RFC proposes to introduce a universal -configuration option to let developers express their intended targets +landscape of versions and feature matrices, so this RFC proposes the introduction of a unique +place and syntax to let developers express their intended targets that all addons can use, +instead of having each addon define it in a different way. This configuration should be easily available to addons, but this RFC doesn't impose -any mandatory behavior on addons. All addons that want to customize their behavior -depending on the target platforms will have a single source of truth to get that +any mandatory behavior on those addons. All addons that want to customize their behavior +depending on the target browsers will have a single source of truth to get that information but it's up to them how to use it. The advantage of having a single source of truth for the targets compared to configure this on a per-addon basis like we do today is mostly for better ergonomics and across-the-board consistency. -Addons that would benefit from this conventions are `babel-preset-env`, `autoprefixer`, -`stylelint` and `eslint` (vía `eslint-plugin-compat`), but not only those. Even Ember itself could, +Examples of addons that would benefit from this conventions are `babel-preset-env`, `autoprefixer`, +`stylelint` and `eslint` (vía `eslint-plugin-compat`) and more. Even Ember itself could, once converted into an addon, take advantage of that to avoid polyfilling or even taking -advantage of some DOM API (`node.classList`?) deep in Glimmer's internals. +advantage of some DOM API (`node.classList`?) deep in Glimmer's internals, helping the goal +of Svelte Builds. # Detailed design -What seems to be the most popular tool and the state of the art on this is the [browserlist](https://github.com/ai/browserslist) -npm package. +What seems to be the most popular tool and the state of the art on building suport matrices +for browser targets is the [browserlist](https://github.com/ai/browserslist) npm package. That package is the one behind `babel-preset-env`, `autoprefixer` and others, and uses the data from [Can I Use](http://caniuse.com/) for knowing the JS, CSS and other APIs available on every browser. -The syntax is also pretty flexible as it allows all sort of complex queries like `Firefox >= 20`, -`>2.5% in CA` (browsers with a market share over 2.5% in Canada) and logical combinations. +The syntax of this package is natural but also pretty flexible, allowing complex +queries like `Firefox >= 20`, `>2.5% in CA` (browsers with a market share over 2.5% in Canada) +and logical combinations of the previous. -The way this library works is calculating the minimum common denominator on a per-feature basis. +The way this library work is by calculating the minimum common denominator support on a per-feature basis. Per example, if the support matrix for an app is `['IE11', 'Firefox latest']` and we have a linter that warns us when we use an unsupported browser API, it would warn us if we try to use @@ -50,22 +53,29 @@ pointer events (supported in IE11 but not in Firefox), would warn us also when u in firefox but not in IE) and would not warn us when using `MutationObserver` because it is supported by both. This library is very powerful and popular, making relatively easy to integrate with a good amount of -tools that use it in little time. +tools that already use it with low effort. -This configuration must be made available to addons but we it's up to the addon authors to take advantage +This configuration must be made available to addons but it's up to the addon authors to take advantage of it. ### Browser support -The configution of target browsers must in a file that allows javascript execution and exports an object -with the configuration. Putting the configuration in a file with javascript execution is important because -allows us to have different config in development and production without having to different keys per -environment or any other environment variable. +The configution of target browsers must be placed in a file that allows javascript execution and exports an object +with the configuration. The reason to prefer a javascript file over a JSON one is to allow users to +dinamically generate different config depending on things like the environment they are building the app in or +any other environment variable. -One option is the `.ember-cli` file. A new dedicated file under `/config` could also -be a good option, much like `config/ember-try.js`. +One possible location for this configuration is the `.ember-cli` file. +A new dedicated named `/config/targets.js` also seems a good option, similar way how addons use `config/ember-try.js` +to configure the test version matrix. -To addons this list of target browsers will be available in `this.project.targets.browsers`. E.g: +Ember CLI will require this file when building the app and make the configuration available to addons +in a `this.project.targets` property. + +This `targets` object contains a getter named `browsers` that returns the provided configuration or the default +one if the user didn't provide any. + +Example usage: ```js module.exports = { @@ -85,7 +95,7 @@ In addition to browsers, Ember apps can run in node using ember-fastboot, but th by the `engines` property in the package.json of the app (or the host app in the case of engines), so no new syntax needed for defining the support. -The minimum supported version of node will be available in `this.project.targets.node`. +This configuration will be available in the same `this.project.targets` object, but on the `node` property. ```js module.exports = { From 21b610245215908153a87f107f13a10b3654314c Mon Sep 17 00:00:00 2001 From: cibernox Date: Fri, 17 Feb 2017 23:19:36 +0000 Subject: [PATCH 12/12] Remove node/fastboot from the scrope of this RFC --- active/0000-standarise-targets.md | 22 +++------------------- 1 file changed, 3 insertions(+), 19 deletions(-) diff --git a/active/0000-standarise-targets.md b/active/0000-standarise-targets.md index a1f8ad2..7e02c0b 100644 --- a/active/0000-standarise-targets.md +++ b/active/0000-standarise-targets.md @@ -89,25 +89,9 @@ module.exports = { }; ``` -### Node support - -In addition to browsers, Ember apps can run in node using ember-fastboot, but this is already covered implicitly -by the `engines` property in the package.json of the app (or the host app in the case of engines), so no new syntax needed -for defining the support. - -This configuration will be available in the same `this.project.targets` object, but on the `node` property. - -```js -module.exports = { - name: 'ember-data', - - included(app) { - this._super.included.apply(this, arguments); - - console.log(this.project.targets.node); // '>= 4' - } -}; -``` +This `targets` object can, and probably will, be expanded in the future with new properties +for different kind of targets, like cordoba apps or fastboot, but that will be +done in a different RFC. # How We Teach This