Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

NVP's future plans for the v2 addon blueprint #121

Open
NullVoxPopuli opened this issue May 17, 2023 · 0 comments
Open

NVP's future plans for the v2 addon blueprint #121

NullVoxPopuli opened this issue May 17, 2023 · 0 comments

Comments

@NullVoxPopuli
Copy link
Collaborator

NullVoxPopuli commented 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):

  • 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
@NullVoxPopuli 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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant