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

Create a cli command for scaffolding out components #7360

Closed
joshblack opened this issue Nov 30, 2020 · 3 comments
Closed

Create a cli command for scaffolding out components #7360

joshblack opened this issue Nov 30, 2020 · 3 comments

Comments

@joshblack
Copy link
Contributor

This issue falls under this KR

We would like to add a new command to @carbon/cli that our team, and others at IBM, could use to scaffold out a component. This scaffold should include a minimal set of conventions that we encourage for teams authoring components, in particular the folder scheme and test conventions.

In addition to generate a standalone folder as an option, this command should include a --lib option (or similarly named) for scaffolding out a component package. This option should be configurable for the following conventions:

  • Testing (Jest)
  • Building (Rollup)
  • Development (Storybook)
  • Linting (ESLint, StyleLint)
  • Commit hooks
@mattrosno
Copy link
Member

mattrosno commented Nov 30, 2020

@joshblack if a component package, can we also include a carbon object in the package.json? If a component folder, would that be a carbon.json or something? What goes in there? Not sure... but eventually information that would replace component index YML files? E.g. https://github.com/carbon-design-system/carbon-website/blob/master/src/data/index/dot-com/callout-media.yml

The carbon config would allow component maintainers to self-document that component's "completeness" (e.g. status, if it's the canonical implementation, how accessible it is, who maintains, etc. Anything of value that would help a user understand the component's history and if it's the right component for their "job".)

Some related concepts:

@mattrosno
Copy link
Member

As for the folder scheme, we've discussed that containing specific markdown files (or structured data somehow) to codify component / pattern templates to assist documentation standardization across the ecosystem.

@joshblack
Copy link
Contributor Author

@mattrosno definitely could add that metadata and include it baked-in, makes a lot of sense to me 👍

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

No branches or pull requests

2 participants