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
@@ -8,14 +8,12 @@ this blog post [Migrating an Ember addon to the next-gen v2 format
8
8
9
9
## WIP
10
10
11
-
This is still work in progress.
12
-
13
-
The blueprint contains a number of assumptions, e.g. using a monorepo using (`yarn` or `npm`) workspaces, with separate workspaces for the addon and the test-app. But there is plenty of room for bikeshedding here, so if you have suggestions about better ways to set this up, then please file an issue to discuss!
11
+
This is still work in progress but we are aiming for this to be the new default for when someone generates an addon with `ember addon super-addon-name`. This will need an RFC to change the default but if you notice anything that you would like to be imporoved with this blueprint please open an issue to discuss, you don't need to wait for the RFC process to give us feedback.
For incremental migration in monorepos, you'll want to also supply the `--skip-git` flag.
115
-
116
46
#### `--typescript`
117
47
118
48
Sets up the new addon with [`typescript`](https://www.typescriptlang.org/) support.
@@ -129,78 +59,6 @@ The blueprint supports `ember-cli-update` to update your addon with any changes
129
59
130
60
For additional instructions, please consult its [documentation](https://github.com/ember-cli/ember-cli-update).
131
61
132
-
### In existing monorepos
133
-
134
-
To generate a new v2 addon inside an existing monorepo, `cd` to that repo's directory and run the command as usual. The blueprint will auto-detect an existing `package.json` and adapt to it. Specifically it will not create or override any files at the root folder, like the `package.json` itself.
135
-
136
-
Most likely though you would not want to use the default locations for the addon and the test app. Instead you should establish a convention how multiple addons and test-apps are located. With the aforementioned path options you can then make the blueprint emit the packages in the correct place.
137
-
138
-
Some more things to pay attention to:
139
-
140
-
- Pass the package manager option ( `--npm`, `--yarn`, `--pnpm`) that you already use!
141
-
- Make sure that the chosen addon and test-app locations are all covered by the configured workspace layout of your package manager!
142
-
- Each package should have a distinct name, so make provide unique names for your test apps instead of the default `test-app` by using the `--test-app-name` option.
143
-
- There is no `start` script at the root `package.json` anymore to start both the addon's build and the test app in watch mode. So you would have to run that `start` script with your package manager in both locations in parallel (separate terminal windows/tabs).
144
-
- Pass the `skip-git` option to not auto-commit the generated files. Most likely there will be things to adapt to you specific requirements before committing.
145
-
- The blueprint will omit all files usually generated at the root folder, including `.prettierrc.js`, and instead use whatever you have already defined in your existing monorepo. So you should run the `lint:fix` script for both the addon and the test-app, and eventually address any non-fixable linting issues or other configuration conventions related to your specific setup.
146
-
147
-
Some examples...
148
-
149
-
#### Group by name
150
-
151
-
We group by the name of the addon, the addon's package and its test app are co-located sub-folders:
0 commit comments