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
To make things "easiest by default", while still also allowing for the correctness for power-users today, I'd like to propose we (eventually):
make the blueprint output a uni-repo by default
this will only be possible once the vite work is finished in the embroider repo
Vite will manage the development environment
tests folder in the addon (but no evidence of an ember app anywhere (as we have with the dummy app in v1 addons)
The details of the test app are wholly within a vite plugin provided by @embroider/addon-dev
same or better browser / CLI ergonomics as in v1 addons (this is prototyped in the glimmer-vm repo)
this would be the only way we can have ember-cli support blueprints / ember g today -- unless we somehow have a way to tell ember-cli about monorepo layouts -- e.g.: generate component in workspace A, and test in workspace B, etc.
make existing flags require the use of a --monorepo flag
This is pretty much the inverse of --addon-only today, but we'd add some assertions so folks are not able to mix and match and potentially observe unexpected behavior (for example, --addon-only with --test-app* doesn't make sense).
Supporting monorepo is still important because it greatly increases the liklihood that an addon is built successfully and is ensured to work once published to npm. Additionally, for testing multiple-dependency scenarios without tons of build macros requires additional test-apps (unless folks like lots of build time conditionals in their test code)
These args would be gated behind --monorepo
--addon-location
--test-app-location
--test-app-name
Obvious caveats:
my plan
i've barely talked about it with folks
lots to do before work here can even start
The text was updated successfully, but these errors were encountered:
NullVoxPopuli
changed the title
NVP's puture plans for the v2 addon blueprint
NVP's future plans for the v2 addon blueprint
May 17, 2023
To make things "easiest by default", while still also allowing for the correctness for power-users today, I'd like to propose we (eventually):
@embroider/addon-dev
ember-cli
support blueprints /ember g
today -- unless we somehow have a way to tell ember-cli about monorepo layouts -- e.g.: generate component in workspace A, and test in workspace B, etc.--monorepo
flagThis is pretty much the inverse of
--addon-only
today, but we'd add some assertions so folks are not able to mix and match and potentially observe unexpected behavior (for example,--addon-only
with--test-app*
doesn't make sense).Supporting monorepo is still important because it greatly increases the liklihood that an addon is built successfully and is ensured to work once published to npm. Additionally, for testing multiple-dependency scenarios without tons of build macros requires additional test-apps (unless folks like lots of build time conditionals in their test code)
These args would be gated behind
--monorepo
--addon-location
--test-app-location
--test-app-name
Obvious caveats:
The text was updated successfully, but these errors were encountered: