-
Notifications
You must be signed in to change notification settings - Fork 35
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
chore(v5): POC of a single package per component (accordion) #3713
base: v5-dev
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like this new structure!
We could refine it a little to make it even clearer for users. For instance, story and test files are for us only, so we could differentiate what really concerns ECL users or not.
@@ -0,0 +1,31 @@ | |||
{ | |||
"name": "@ecl/accordion", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
for the package name (removing "component"), is it to avoid confusion with existing packages?
My concern is that we may have some conflict later between component and other ECL packages. For instance, if we have to add a component named "builder" or "event-manager" (not sure why, but who knows...).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
the story and test files are ignored by npm, so they are not in the distributed package, as it is already in v3, i wouldn't create "folders" to nest those files in...
About the naming, it seems straighftorward now that we would unify everything in a single package to just use the component's name, we can add any prefix we want, like "component-accordion" but what is that for..?
Currently, for instance, the builder package is already simply @ecl/builder, i hardly see how in the future this might conflict with other packages that we distribute as ECL.
No description provided.