Closed qeleb closed 1 year ago
It's nice that the other pull request is in. I had been excited to transition to Yarn v3, but I felt like it should happen after.
Next, I plan to take a look at correcting the way the CSS is minified. Did you see the issue I posted?
Totals | |
---|---|
Change from base Build 2998383451: | 0.0% |
Covered Lines: | 250 |
Relevant Lines: | 250 |
Next, I plan to take a look at correcting the way the CSS is minified. Did you see the issue I posted?
Yep, I see that. Makes sense. I have so limited time to care for this repo right now and using that limited time fully to check your PRs :D Thanks
One question. Does yarn v3 affect the template in any way? I mean people using different yarn versions wouldn't see any difference right?
One question. Does yarn v3 affect the template in any way? I mean people using different yarn versions wouldn't see any difference right?
this is actually the coolest part about yarn v3. It uses the exact same globally installed yarn package (which is v1), but it checks for version in .yarn/releases and is enhanced by it. In effect, the yarn v3 enhancement is stored directly in the repository. No upgrades are required on the user’s end. Additionally, we can now add yarn plugins in here and commit these directly to the repository.
Don't you need .yarnrc.yml
included in the template? Otherwise, how does it know which plugins to include?
Don't you need
.yarnrc.yml
included in the template? Otherwise, how does it know which plugins to include?
yes, it will need to be included. this file tells yarn where the v3 enhancement and plugins are. it’s sort of like package.json for yarn.
I’ve updated the .gitignore to allow all necessary yarn files and ignore all others.
Then you need to modify this file as well otherwise template folder will not have it inside
Then you need to modify this file as well otherwise template folder will not have it inside
ah right. good call. I forgot to do this. I will be able to commit this in about 8 hours.
EDIT: this is much harder than I realized. Yarn berry will need some kind of workaround to have nested workspaces the way we currently do.
What do you mean by nested workspaces? This isn't a monorepo
What do you mean by nested workspaces? This isn't a monorepo
yarn 2+ does not like executing in a folder where any of its parents have a yarn.lock.
I didn’t spend a lot of time looking into it.. I just determined that the fix is a little more involved than i realized
I see you removed some npm files but I think we should keep npm features. Yarn is optional still. I know people go with npm a lot. I'll take a look at the broken cra-app script. it's for testing locally doesn't really affect the template
Creating CRA from the custom template using the local folder doesn't work in yarn 3. There is something wrong with it but I don't wanna hunt the bug in their source code. I'm fine with using yarn 1 to generate app locally.
I will revisit this PR in the next few days..
I'll scale it back to just these things:
-Upgrade eslint, @types/node, & react-i18next -Changed enums to const enums. It is always a good idea if it can be const... see why here -Touch up documentation relating to routing -Add yarn v2-3 filenames to .gitignore and add some documentation about it and some plugins that I'd recommend... this is the best I can do because I haven't figured out how to use yarn v3 for the purposes of this boilerplate yet. -Add myself as a contributor in the readme & .all-contributorsrc
I think this is just fine. I am going to merge it. Just I wanna keep the .npmrc file as well that was it.
What I meant above is that somehow testing the custom template locally with yarn 3 is not working and I am pretty sure it's the fault of CRA. Switching yarn versions is easy and It will be rarely needed until cra fixes the issue I hope.
I think this is just fine. I am going to merge it. Just I wanna keep the .npmrc file as well that was it.
What I meant above is that somehow testing the custom template locally with yarn 3 is not working and I am pretty sure it's the fault of CRA. Switching yarn versions is easy and It will be rarely needed until cra fixes the issue I hope.
I think the issue is in the way yarn 2-3 works actually. It seems that yarn will choose to use the highest yarn.lock and node_modules in the directory structure. This allows for much faster installing and much less wasted storage space, but it will require a change to the way we initiate packages using the boilerplate. I haven’t had much time to look into it over the past few days, and am thinking that regressing it until i better understand it might be the best choice.
there are some other side effects too… yarn 3 doesn’t seem to call “prepare” like npm after install.. it calls “postinstall”, so we could switch it to that for husky.
also, I think the .npmrc is not very helpful. It’s a file that is only respected by npm (which is problematic and not officially supported by this repo anyway) and all it does is prevent the installer from adding the caret on a new package’s version.
The problem with initiating the custom template locally is not only the higher yarn lock it finds. I tried initiating from different directories with no success. CRA calls yarn with --exact option giving local folder as a package URL. Yarn 3 throws error in this case. This has nothing to do with finding yarn.lock.
I tried quite some ways of instantiating locally but I couldn't at all (with nested folder or with totally different directories)
Take a look at my other PR? I plan to close this one in favor of it.
closing this since the other is merged then
New stuff
1) Upgraded to Yarn v3 from Yarn v1
2) Added Yarn typescript plugin.
3) Added direct dependency on eslint & jest to get rid of loads of warnings that plagued yarn install 4) Upgraded eslint, @types/node, & react-i18next 5) Changed enums to const enums. It is always a good idea if it can be const... see why here 6) Finally... I added myself as a contributor in the readme & .all-contributorsrc