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

docs: inconsistency between addon-author-guide.md and ember-welcome-page #1754

Closed
BlueCutOfficial opened this issue Jan 16, 2024 · 5 comments · Fixed by #1765
Closed

docs: inconsistency between addon-author-guide.md and ember-welcome-page #1754

BlueCutOfficial opened this issue Jan 16, 2024 · 5 comments · Fixed by #1765

Comments

@BlueCutOfficial
Copy link
Collaborator

In the Addon Author Guide, the section Support Level Embroider Native gives ember-welcome-page as an example of V2 addon not using a monorepo:

it's also OK to keep your test app in a subdirectory of your addon. This is closer to how V1 addons work, where tests/dummy serves this purpose. See ember-welcome-page for an example of not using a monorepo -- instead it has a test-app subdirectory and uses the addon-dev command from @embroider/addon-dev to manage linkage between the addon and the test-app and to manage combining of dependencies from both into a single top-level package.json

This example is from Nov 2, 2021 and it seems ember-welcome-page structure has changed since then. Is there any other V2 addon that could serve as an example?

@void-mAlex
Copy link
Collaborator

hello @BlueCutOfficial
are you looking for a way to keep the same structure on v1 addons with the test app under the addon?
apps and addons need different dependencies so them living under one package json is not a great idea which is why v2 addons have been moving to monorepo setups as it's the easiest to set up and have now gained support on all the major package managers
I would suggest that the addon author guide could do with some updating if you're interested :)

@BlueCutOfficial
Copy link
Collaborator Author

Hey @void-mAlex ,

I am not looking for a way to keep the same structure with the test app under the addon. I was simply going through the docs about migrating V1 to V2 and I noticed that this specific part is out of date, because ember-welcome-page structure no longer matches what is described.

I don't have an opinion about how to fix the doc: "is the described solution not recommended at all and should be removed from the docs" or " it's still valid but it should point out something other than ember-welcome-page". Also, I am not aware if other parts of this doc could be out of date as well?

@void-mAlex
Copy link
Collaborator

not sure what others think on this, but for my two cents, I think we should update the addon guide to recommend people use separate packages like the addons named in the doc do (including ember-welcome-page)
happy to take prs to that effect

@mansona
Copy link
Member

mansona commented Jan 17, 2024

Sorry I was going to reply to this yesterday but I didn't get a chance.

The issue that we have right now is that there is no legitimate way to consume a v2 addon without having a full test app package in a monorepo. This is something that I am very much sad about and it's one of the reasons that I was working on bottled-ember to allow us to have an addon that lives at the root of a repo and still can provide a test app and docs apps etc.

After a lot of discussion with Ed, this work has been put on pause until we get to the next phase of being able to sensibly boot an ember app without the need for a full package. That way we could make the default experience of someone building a somewhat simple addon not require a full monorepo setup with all the hassle that can bring.

To answer your original question I would probably remove the reference to welcome-page as you have pointed out it doesn't reflect reality right now. The update guide could do with some love, updating things and making sure we don't refer to things that are no longer true

@BlueCutOfficial
Copy link
Collaborator Author

@mansona do you think #1765 is good enough as a quick fix? (I am not aware of what else could be changed)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
3 participants