-
Notifications
You must be signed in to change notification settings - Fork 989
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
Vendor create app template #1637
Conversation
This is great @pepibumur! So we're failing the lint check on the "overrides": [
{
"files": [
"*/templates/web/src/Routes.*"
],
"rules": {
"no-undef": "off"
}
}
] |
Does this have any implications for the all-contributors stuff? @thedavidprice? |
@thedavidprice / @peterp I followed your suggestion to disable the rule in the template directory and after trying different wildcards, I realized that eslint was not reading the configuration. Then I extended the |
@pepibumur I'm checking this out now - if you have some time would you push up your changes? |
@pepibumur This is now resolved... turns out we never used the configuration file 🤦♂️ |
@Tobbe I removed all the ESLint warnings in this PR 😆 |
|
Ouch. Thanks for looking into it @peterp. Do I have to do anything else on my side? |
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.
Artifact files
If this is no longer a Repo, the following changes can be made:
- delete
template/.gitignore
- rename
template/.gitignore.app
to/template/.gitignore
- delete
template/README.md
- rename
template/README_APP.md
totemplate/README.md
- remove
title: 'Clean up
task block starting L96 insrc/create-redwood-app.js
Misc To-Dos
- update the package
create-redwood-app/README.md
--> maybe easier to create a new issue and assign to me @thedavidprice - @peterp during NPM publishing, we'll need to somehow include a step where the
@redwoodjs
packages in the respectivetemplate/*/package.json
are upgraded to the version being published, yes?
Nice work on this one @pepibumur! I've added some review changes separately. Discussion & questions below: Discussion1. Test(s)@pepibumur were you thinking about adding a test for Either way, we should run a Windows test before releasing (assuming Pedro isn't on Windows). 'Cause Windows + Paths always seem to bite us. 2. Possible to Manually Setup?In the past, there have been occasions where people could not get
3. Incrementing Template Release with
|
looping in @aldonline --> given your refactoring of Structure package, I thought this PR might be of interest and, hopefully, helpful! ('Cause using it as fixture for Structure tests or something like that...) |
Let's manually test this on Windows. Nothing sticks out to me as problematic. This is way simpler than before, and we're not changing much.
Those issues should not exist anymore. If you can run
This is still possible. Instead of using lerna to release we'll change the version and use The exact steps would be:
|
@pepibumur I'll quick run through @thedavidprice's suggested changes. I'm pretty eager to get this done, since it's blocking some work that @Tobbe is doing on stripping out Apollo's packages. |
@peterp I'm on standby to (manually) test this on Windows. Just ping me. |
For my own curiosity and opportunity to learn -- When/why was this needed? When can't we just do a patch-release of everything when the template needs to be updated? |
We had a situation where the create-react-app template would be broken, but the packages were not. We did not want to republish all the packages, and just wanted to tag a new release in the Tagging a release in the repo would mean that it was the template that was downloaded with But, you're right, for the sake of simplicity, if the template is broken we should bump and release all the packages again. |
Yeah, automate the release process more, and it'll be easier to just cut a new patch release for everything. Which is the correct thing to do looking at SemVer. Make it easier to do the right thing! 🙂 |
@peterp 1. TestsMakes sense for getting this one out the door. And, once it's merged, this sets us up for improving CI by setting up a GitHub action that runs the Integration test using canaries after a PR is merged. I suggest this is a high priority and will create an Issue now and add to v1 Roadmap. 2. Manual SetupI'm also assuming the problem (encountered by few that I know) will resolve if not go away entirely. I'm anticipating the question hitting our forums, though. Will figure it out if and when... 3. Incrementing Template Release (aka only publishing CRWA package)Publishing steps look great and make sense. However, maybe this is the answer to my question, which is based on previous practices --> once the CRWA template is merged into main repo, we will NEVER publish the CRWA package separately as a non-patch, incremental release. Instead, we will always publish all packages together at same semver release. Seems like the way to go, yes? (Thanks for letting me think through it here.) |
@peterp has this item been addressed? I am assuming it's not automatically handled by Lerna — maybe it is?
|
@thedavidprice We would have to run |
This might be where I'm confused, but I think we'd run into an infinite loop:
Based on this understanding, it seems we'll need to handle changing the Template package versions at the same step as the Lerna publishing. |
Ah lol, you're right. Maybe we need some TENET action. I'll write a script that updates this and the other packages: #1661 1661 |
Having the
create-redwood-app
template in a different repository adds some indirection that can be avoided. This PR adds the template to thecreate-redwood-app
package under/template
and updates the generation code to copy the content from there instead of downloading it from GitHub releases. Thanks to this change it's easier to test template changes since it doesn't require adjusting the logic to read the template from a different source.In a follow-up PR I'd like to add a few tests and start adding support for generating the mobile side.