Nice article 😊 I definitely agree with some of your points, especially around good naming and directory structure, and configuring aliases for your imports (ie. @components/SomeComponent 😍). However, I do have to disagree with a couple of your suggestions.
You should never use an absolute path for your imports. The reason being that the absolute path on one machine is not going to be the same on another one. This may work in a containerized application, but is definitely not a one-size fits all. If relative paths are a problem for your application, I would Highly recommend taking the time to set up aliases as you mentioned in the first suggestion instead of using absolute paths. 🔃
Barrel files cause lots of problems. Build performance issues, bundle size impacts, breaking of Intellisense and autocompletion, and all the hassle they can cause with Typescript (if you're using it). I can't tell you how many hours I've spent trying to fix circular dependencies that were caused by barrel files! Barrels are for aging wine and whiskey, please don't use them for code! 🥃🍷
To end on a positive note, I 100% agree with #5! Properly formatted and standardized code matters so much. It's so hard to work on a project that lacks the use of tools like these. So great point here!
Thanks for the article and starting some great conversation on the topic of best practices!
I think for absolute paths he ment @ rule paths provided by TS which will be resolved while compiling by TS and for a project paths starting from SRC will always going to be same in all machines for same project
when he says absolute path
He means this -> "src/component/home.ts"
He doesn't mean this -> "D:/work/react-projects/my-test-project/src/component/home.ts"
Nice article 😊 I definitely agree with some of your points, especially around good naming and directory structure, and configuring aliases for your imports (ie.
@components/SomeComponent😍). However, I do have to disagree with a couple of your suggestions.You should never use an absolute path for your imports. The reason being that the absolute path on one machine is not going to be the same on another one. This may work in a containerized application, but is definitely not a one-size fits all. If relative paths are a problem for your application, I would Highly recommend taking the time to set up aliases as you mentioned in the first suggestion instead of using absolute paths. 🔃
Barrel files cause lots of problems. Build performance issues, bundle size impacts, breaking of Intellisense and autocompletion, and all the hassle they can cause with Typescript (if you're using it). I can't tell you how many hours I've spent trying to fix circular dependencies that were caused by barrel files! Barrels are for aging wine and whiskey, please don't use them for code! 🥃🍷
To end on a positive note, I 100% agree with #5! Properly formatted and standardized code matters so much. It's so hard to work on a project that lacks the use of tools like these. So great point here!
Thanks for the article and starting some great conversation on the topic of best practices!
I think for absolute paths he ment @ rule paths provided by TS which will be resolved while compiling by TS and for a project paths starting from SRC will always going to be same in all machines for same project
when he says absolute path
He means this -> "src/component/home.ts"
He doesn't mean this -> "D:/work/react-projects/my-test-project/src/component/home.ts"
I can certainly see what the author meant to convey here as you describe. However, the term "absolute path" has a very specific meaning:
What you and the author are referring to actually has different names depending on the tool you're using.
In Next.js, these are called Absolute Imports.
In Svelte, these are called Aliases.
They are also called Aliases in Nuxt.js
I hope this adds some clarity to my origin comment 😃