You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
| --type | String | Empty (match all types in path) | Apply transformation to only passed type. The type can be one of `services`, `routes`, `components`, `controllers`|
29
-
| --runtime-config-path | File path | Empty | Transformation using runtime configuration from the path |
30
23
31
24
### Class Fields
32
25
@@ -57,7 +50,7 @@ For example, the below declaration
57
50
```
58
51
import { inject as service } from "@ember/service";
59
52
const Foo = EmberObject.extend({
60
-
b: service("store"),
53
+
store: service(),
61
54
});
62
55
```
63
56
@@ -66,12 +59,11 @@ Will be transformed to
66
59
```
67
60
import { service } from "@ember-decorators/service";
68
61
class Foo extends EmberObject {
69
-
@service("store")
70
-
b;
62
+
@service store;
71
63
}
72
64
```
73
65
74
-
**Note** The decorators support is not built in inside Ember. Decorators support requires the use of the [ember-decorators](https://github.com/ember-decorators/ember-decorators) addon and should be added as dependency to your application. The codemod takes care of importing required decorators from the `ember-decorators` addon.
66
+
**Note** The decorators support is built into Ember by way of ember-cli-babel@7.7.0 or higher.
75
67
76
68
### Types
77
69
@@ -88,47 +80,12 @@ The path of the file being transformed is matched against the glob pattern of th
88
80
89
81
If a type is not provided, the codemods will run against all the **_types_** in the path provided.
90
82
91
-
### Runtime Config Path
83
+
### Runtime Config
92
84
93
85
As per conventional codemods, the code is converted from one API to another by statically analyzing patterns within it. While this works well most of the time, there are cases that can only be analyzed at runtime to determine the full shape of the code to transform. For example, if we need to determine the class hierarchy, it is not possible with static analysis to determine the parent classes and their properties.
94
86
95
87
The codemods are designed with `runtime data` as input to correctly transform the code. For each file currently being transformed, the codemods need a `configuration file`, which will provide additional metadata about the properties of the ember object.
96
88
97
-
The runtime config path must point to a JSON file containing runtime data of the format:
98
-
99
-
```
100
-
{
101
-
data: [{
102
-
"/absolute/file/path": {
103
-
"computedProperties": ['computedProp1', ...],
104
-
"observedProperties": ['observedProp1', ...],
105
-
"observerProperties": {
106
-
"observerProp1": ["prop1", "prop2", ...]
107
-
},
108
-
"offProperties": {
109
-
"offProp": ["prop3", ...]
110
-
},
111
-
"overriddenActions": ["overriddenAction1", ...],
112
-
"overriddenProperties": ["overriddenProp1"],
113
-
"ownProperties": ["prop1", ...],
114
-
"type": "Component|Route|Controller|EmberObject",
115
-
"unobservedProperties": {
116
-
"unobservedProp1": ["prop1", ...]
117
-
}
118
-
}
119
-
}]
120
-
}
121
-
```
122
-
123
-
_How to get this runtime data from an ember application_
124
-
125
-
There are tools available which provide various ways of extracting runtime data. The following are examples:
A [dyfactor plugin](https://github.com/ssutar/ember-es6-class-codemod-dyfactor) has been developed to extract runtime data from an ember application. However any tool which provide the runtime data with the expected format can be used with these codemods.
131
-
132
89
## Debugging
133
90
134
91
The codemods log execution information in the `codemods.log` file in the current directory from where the codemods are being executed. Specifically, details such as failures and reasons for failures, are logged. This would be the recommended starting point for debugging issues related to these codemods.
0 commit comments