feat(generators): support for component subdirectory

[frankcalise]

Please verify the following:

• yarn test jest tests pass with new tests, if relevant
  • No subdirectory passes
  • Subdirectory generated, relative paths unneeded by adding TS absolute path alias
• README.md has been updated with your changes, if relevant

Describe your PR

• Closes Generate a component in specific path/subfolder #1746
• Supports components to be generated in a subdirectory
• Supplies frontmatter props with subdirectory (to extend other templates)
• Added test to check the output of both root components and subdirectory nested components
• Updated documentation for new prop

[frankcalise]

@kateinkim @joshuayoes @jamonholmgren

Any suggestions here to solve the relative path import back to the Text component and theme imports?

I could of course clear out the Text component and remove the associated style.

How do we feel about adding a prop for relativeThemesPath and relativeComponentsPath?

[joshuayoes]

Instead of adding multiple props, what if we just included one relativeAppPath prop? Then we wouldn't need to add props for each app subdirectory

It would make the paths a little more verbose than necessary in the output, but I think it would be more clear writing them in the generator file.

The generator would look something like this:

import { colors, typography } from "<%= props.relativeRootPath %>/theme/colors"
import { Text } from "<%= props.relativeRootPath %>/components/Text"

The test case generate component sub/to/my/Topping would output this:

/app/components/sub/to/my/Topping.tsx

import { colors, typography } from "../../../../../theme/colors"
import { Text } from "../../../../components/Text"

Then the user can manually update it if it bother them

[joshuayoes]

I think the alternative solution here would be to add typescript alias paths to ignite

[frankcalise]

I think the alternative solution here would be to add typescript alias paths to ignite

Ah right, which I did in a cookbook recipe. Good thought also.

[kateinkim]

@frankcalise Sorry I'm not feeling so great right now so I might be missing something but I'm not really clear on the distinction we're making here between subdirectory and destinationDir (example here). It seemed like #1746 would be resolved with the existing destinationDir except maybe allowing it to be overwritten via CLI.

[frankcalise]

@frankcalise Sorry I'm not feeling so great right now so I might be missing something but I'm not really clear on the distinction we're making here between subdirectory and destinationDir (example here). It seemed like #1746 would be resolved with the existing destinationDir except maybe allowing it to be overwritten via CLI.

Don't be sorry @kateinkim! You are correct in that destinationDir does tell the generator where to stash the new file. From what I gathered in #1746 (and I could be interpreting incorrectly), is that since we were considering the CLI parameter in some fashion that it would be more dynamic then just changing destinationDir each time you were going to generate a component.

@jamonholmgren want to weigh in here?

[joshuayoes]

I wrote another draft PR of an idea to make implementing this easier: #2317

If we go with using a tool like zx with generators, this could potentially be thrown in the ignite cookbook

[joshuayoes]

This looks good! I'm a fan of the ~/ alias.

[jamonholmgren]

Looks good to me!

[infinitered-circleci]

🎉 This PR is included in version 8.6.0 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀