PatternFly project generators (npm init / yarn create, and perhaps a create-react-app template) #4821
mturley
started this conversation in
Feature requests
Replies: 1 comment
-
I am starting a new PatternFly project, What do you recommend at this point? |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
I've been starting a few projects with patternfly-react-seed lately and comparing it with other methods of generating a React app and setting up PatternFly. I think it could be really cool to provide officially supported ways to automatically generate a PatternFly React app! I think there are two main ways we could do this, and perhaps we may want to do both. I don't think this should replace patternfly-react-seed; in fact the first of the two options could leverage it directly.
We could create an npm initializer package / starter kit to be used with
npm init
and/oryarn create
!create-*
by runningnpm init *
oryarn create *
, so for example if we published acreate-patternfly-react-app
package, it would be usable by runningnpm init patternfly-react-app my-new-app
oryarn create patternfly-react-app my-new-app
. Both follow the same behavior of just running the main bin script of the package (npm init
does this vianpm exec
/npx
, whileyarn create
does it by installing the package globally or updating it if already present).create-react-app
tool, which you can use by runningnpm init react-app my-new-app
oryarn create react-app my-new-app
. In their case, they detect which package manager you're using and generate an app that uses that package manager (adjusting the README and usingpackage-lock.json
oryarn.lock
as appropriate). In theory, we could do the same.npm init
supports scoped packages, whereyarn create
does not appear to (at least it's not mentioned in their docs). So if we wanted to keep this initializer package within our@patternfly
scope on npm, we'd have to limit our support tonpm init
and notyarn create
. This may be fine since we already only support npm in the seed app repo. If we do that, we could publish our initializer as@patternfly/create-react
to have the command benpm init @patternfly/react my-new-app
. I do think we should avoid the name@patternfly/create-react-app
so as not to confuse people who are familiar withcreate-react-app
.commander
to support additional CLI arguments,validate-npm-package-name
to check that the user-provided app name is valid, enforces a minimum Node version, creates a directory containing a minimal package.json file, and then installs dependencies and extracts templates in a scripted fashion. That last step is probably overkill for us, but it may be worth trying to automate updating the generated app's dependencies to at least the newest minor version bumps after the ones in patternfly-react-seed. It would probably be to our advantage to have as much of the guts of the generated app come from patternfly-react-seed as possible so we don't have to update both repositories in order to support creating apps both ways.This may be less desirable since we already have a fully-fledged seed app with custom webpack configuration, but for people who want a simpler setup or who are already familiar with
create-react-app
and just want a quick way to use PatternFly with it, we could create our own custom template for create-react-app.cra-template-*
to be used when running create-react-app with the--template *
option. We could base our template on the existingcra-template-typescript
(the default CRA template still uses plain JavaScript), and publish it ascra-template-patternfly
. Consumers could generate a starter PatternFly app with minimal configuration by runningnpx create-react-app --template patternfly my-new-app
, ornpm init react-app --template patternfly my-new-app
, oryarn create react-app --template patternfly my-new-app
.eject
and generate the configuration being used internally. It is a great tool for people first learning React or for quick one-off projects, and having a template for it may be useful for us to get those people using PatternFly more quickly.--template typescript
, installing the PF react packages as dependencies, and importing our stylesheets as simply as this (no webpack config changes necessary):I think (1) is a good idea either way, as an enhancement to our existing patternfly-react-seed experience. (2) may or may not be desirable because it may be confusing to have multiple officially supported ways to start a PatternFly app, but CRA is such a popular tool that it would be nice to be part of that ecosystem. Personally, I would use the seed initializer for starting new actual Red Hat projects, and I would use the CRA template for toy projects and one-off sandboxes for testing things. These projects could coexist and reference each other for simple and advanced use cases.
Just imagine:
Beta Was this translation helpful? Give feedback.
All reactions