Love this type of content. Feels like we are having a talk, developer to developer. I have to be honest, I haven't watched much of your content, but this is really nice! Keep it up!
Applications are not packages. Applications have entry points where package generally do not have this. Split up your monorepo into apps and packages and it will become much more cleare that the shared stuff lives in the packages and is consumed in the applications.
I have used monorepo earlier and switched away from it. My reasons - configuration fatigue, you outlined out as well - every framework has a separate configuration to get absolute imports working, you noticed this problem as well - an explosion of configuration files, each of which has to configured at once while beeing slighly different - biggest reason: big slowdown of the autocomplete (taking like 3-10 seconds) because it starts/calls the language server lazily and the high memory requirements, because it runs each project in a separate process I came to the conclusion that it's better to have - on big projects: the dependant packages build and imported (how its designed to work, like package manager do it) - on small projects: just copy the code and/or separate logical parts based on directories
Would you be open to the idea of doing a video running through the software architecture of the game? :) I glanced through the repo and realised you built everything pretty much ground-up without any game engine! Impressive feat.
I learned about absolute paths back in 2018 while working with Angular, and it totally changed my life. I've never used those nasty "../.../.../component.ts" paths again 🤮
There is also a “native” way. Path aliases via package.json “imports”. They have to start with “#” and also support isomorphic importing - so different modules are being imported based on the platform (node vs browser) within the same import statement. This approach worked way better for me than the ts approach, even in a ts project. Not sure if its possible to alias outside of the package folder, though. Only used it inside a single package so far.
I think the refractoring could be done till the specific directory level where the imports can be more sorted like @/entities/items/spikes, tree etc, this would help to centralize the imports more specifically where one can know that these imports are from entities and if needed more information then can check the tsconfig. Also each directory can contain a index.ts file that exports all the other files and that can be used to consume the imports in other directories.
Why did you merge the PR if you still have some bugs? It looks like TS bugs - which should show up when you run tsc. Just curious, I'm a jr but always make sure anything I touch didn't break anything else before putting up a PR
There’s a difference between bugs and typescript just not able to figure stuff out. If the game still works, I can run around and pick items up and shoot zombies then there’s no bugs in my opinion.
Dont use "paths" to reference other projects, it may work flawlessly only in self referencing (just to shorten some relative paths). Such configured packages won't work after transpiling into js and run thru node. Node project may not access the code outside of its boundaries. You may want to run some shared code both on the server and the client. It is not so well baked solution. It is better to use: pnpm workspaces + "exports" section of package.json with conditions. It is possible to achieve well working HMR in dev and fully nodejs compatible js code after transpilation.
Damn! I totally agree man. Recently, I had to deal with a lot of shit with tsconfig in our monorepo. I had stop using path aliases altogether. Man, it was exhaustingggg.
You should definitely consider ditching next for react router 7 or remix! All the client is doing is rendering a canvas, and next doesn't bring any benefits and is very bloated and slow.
Nice video and good point at the end, the whole js ecosystem and frameworks like nextjs are soooo bloated and you spend more time in config files instead of doing the programming. People really need to move away from all of that and go back to basics imo, and please, especially juniors, stop watching guys talking about nextjs like it's the best thing ever made because it's not, it really feels like they are paid to say that 😂, just use go and enjoy your time programming. I was one of them back in the day 😅
Agree for the most part but I think there is a value in using NextJS. It doesn't make sense to cobble together the same functionality that NextJS has already created and optimized for if you need it. Spending time in config files is a waste of time but so is recreating the cache system or specific middleware that's provided in NextJS
the reason ts will always lose to other typed languages is the fact that project wide error reporting is very heavy on the ts server and inapplicable for any medium sized or larger project. This is also not an easy solve as the ts server will be very hard to rewrite in a more performant language as the complete spec is not found within a single document.
![I.N "HALLUCINATION" | [Stray Kids : SKZ-PLAYER]](http://i.ytimg.com/vi/n5B5q1Hwt_U/mqdefault.jpg)
Love this type of content. Feels like we are having a talk, developer to developer. I have to be honest, I haven't watched much of your content, but this is really nice! Keep it up!
Applications are not packages. Applications have entry points where package generally do not have this. Split up your monorepo into apps and packages and it will become much more cleare that the shared stuff lives in the packages and is consumed in the applications.
good point!
No entry point sounds more like library than package to me. I’ve found the term package used in many ways.
@@jamess.2491In NodeJS libraries are typically called packages within the npm (package manager) ecosystem.
yeah that's what we do and how it should be done.
Yeah I agree that’s how it’s normally done
I have used monorepo earlier and switched away from it. My reasons
- configuration fatigue, you outlined out as well
- every framework has a separate configuration to get absolute imports working, you noticed this problem as well
- an explosion of configuration files, each of which has to configured at once while beeing slighly different
- biggest reason: big slowdown of the autocomplete (taking like 3-10 seconds) because it starts/calls the language server lazily and the high memory requirements, because it runs each project in a separate process
I came to the conclusion that it's better to have
- on big projects: the dependant packages build and imported (how its designed to work, like package manager do it)
- on small projects: just copy the code and/or separate logical parts based on directories
Would you be open to the idea of doing a video running through the software architecture of the game? :)
I glanced through the repo and realised you built everything pretty much ground-up without any game engine! Impressive feat.
yeah, for sure. I want to make sure I have it more polished before I do that though.
i have the same feeling lil broski
have you tried turbo repo? it will cache your package builds.
not yet
@@WebDevCody would highly recommend
@@WebDevCody +1 for turbo
It doesn't work with Tailwind, right? Monorepo either.
@@Soradark2what about nx, Whats better
Good job love ❤
It's so wholesome you comment on every video and always first comment 😂did cody write a script to do it ? :P jkjk love webdevcody
I learned about absolute paths back in 2018 while working with Angular, and it totally changed my life.
I've never used those nasty "../.../.../component.ts" paths again 🤮
There is also a “native” way. Path aliases via package.json “imports”. They have to start with “#” and also support isomorphic importing - so different modules are being imported based on the platform (node vs browser) within the same import statement. This approach worked way better for me than the ts approach, even in a ts project. Not sure if its possible to alias outside of the package folder, though. Only used it inside a single package so far.
I think the refractoring could be done till the specific directory level where the imports can be more sorted like @/entities/items/spikes, tree etc, this would help to centralize the imports more specifically where one can know that these imports are from entities and if needed more information then can check the tsconfig. Also each directory can contain a index.ts file that exports all the other files and that can be used to consume the imports in other directories.
Great video. That's actually a good way to maintain a monorepo without special tooling like turbo. Btw, have you ever tried the latter?
I thought you could do something similar with the paths (@) in the package.json, so you don't have to set it up in multiple places.
Why did you merge the PR if you still have some bugs? It looks like TS bugs - which should show up when you run tsc. Just curious, I'm a jr but always make sure anything I touch didn't break anything else before putting up a PR
There’s a difference between bugs and typescript just not able to figure stuff out. If the game still works, I can run around and pick items up and shoot zombies then there’s no bugs in my opinion.
Dont use "paths" to reference other projects, it may work flawlessly only in self referencing (just to shorten some relative paths). Such configured packages won't work after transpiling into js and run thru node. Node project may not access the code outside of its boundaries. You may want to run some shared code both on the server and the client. It is not so well baked solution. It is better to use: pnpm workspaces + "exports" section of package.json with conditions. It is possible to achieve well working HMR in dev and fully nodejs compatible js code after transpilation.
Any reason you didn't try with turbo repo?
Should solve some of the wierdness as the docs walks you through it
This video is exactly how I feel with ts configs. I think you want NPM workspaces instead of using paths.
Hope you never ever need to change baseUrl for whatever reason.
Damn! I totally agree man. Recently, I had to deal with a lot of shit with tsconfig in our monorepo. I had stop using path aliases altogether. Man, it was exhaustingggg.
Cool!!!!!
You should definitely consider ditching next for react router 7 or remix! All the client is doing is rendering a canvas, and next doesn't bring any benefits and is very bloated and slow.
I may do this
I dunno about TS being the best language for web dev. These days i’d much rather use PHP. Its got typing and the ecosystem is straight forward.
Nice video and good point at the end, the whole js ecosystem and frameworks like nextjs are soooo bloated and you spend more time in config files instead of doing the programming.
People really need to move away from all of that and go back to basics imo, and please, especially juniors, stop watching guys talking about nextjs like it's the best thing ever made because it's not, it really feels like they are paid to say that 😂, just use go and enjoy your time programming. I was one of them back in the day 😅
Remix?
Agree for the most part but I think there is a value in using NextJS. It doesn't make sense to cobble together the same functionality that NextJS has already created and optimized for if you need it. Spending time in config files is a waste of time but so is recreating the cache system or specific middleware that's provided in NextJS
Why would anyone want this
the reason ts will always lose to other typed languages is the fact that project wide error reporting is very heavy on the ts server and inapplicable for any medium sized or larger project. This is also not an easy solve as the ts server will be very hard to rewrite in a more performant language as the complete spec is not found within a single document.