Refactoring to include husky pre-commit hooks, improved eslint rules and manual chunking + more

[barrymun]

Description

• refactor eslint rules for more consistent commits
• install husky pre-commit hooks
• chunk some of the larger build files
• adding vite-tsconfig-paths to make imports more consistent
• barrelling imports

Type of Change

• ✨ New snippet
• 🛠 Improvement to an existing snippet
• 🐞 Bug fix
• 📖 Documentation update
• 🔧 Other (please describe): A refactor to make future commits consistent, and adds pre-commit hooks to catch potential errors before a commit is made.

Checklist

• I have tested my code and verified it works as expected.
• My code follows the style and contribution guidelines of this project.
• Comments are added where necessary for clarity.
• Documentation has been updated (if applicable).
• There are no new warnings or errors from my changes.

Related Issues

Closes #

Additional Context

Screenshots (Optional)

Click to view screenshots

[netlify]

✅ Deploy Preview for quicksnip ready!

Name	Link
🔨 Latest commit	1a7106f
🔍 Latest deploy log	https://app.netlify.com/sites/quicksnip/deploys/6774f96ee4d8050008218ba1
😎 Deploy Preview	https://deploy-preview-73--quicksnip.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[barrymun]

Really like quicksnip and wanted to help a little. I couldn't find any open issues pertaining to some of the changes that I'm proposing above, but if these are already being addressed then feel free to close this PR. This PR should clean up the codebase a little and make the code more consistent. If there are any questions please ask. Some of the changes are personal preference that crept in and can be ignored/removed if another pattern has already been established.

[Mathys-Gasnier]

Hey, thanks for your contribution !
I'm not a big fan of the index.ts everywhere just re exporting stuff... But let's wait on other feedbacks

[technoph1le]

Hey, there. Thank you for the contribution. Glad you liked our project.

Our maintainers will review the PR. Please, it would be great if you first create an issue before making (big) changes in the codebase next time. It would help us understand what you're trying to tackle/build. If we're already working on it, it would save you time as well.

Thank you for understanding.

[barrymun]

Hey, there. Thank you for the contribution. Glad you liked our project.

Our maintainers will review the PR. Please, it would be great if you first create an issue before making (big) changes in the codebase next time. It would help us understand what you're trying to tackle/build. If we're already working on it, it would save you time as well.

Thank you for understanding.

Hello, thanks for your reply. In future I will create an issue, but I was unsure of whether or not I should have done this at the time as the above code doesn't fix anything - it's more of a quality of life change. PR looks big but it's mostly eslint libs that have been added.

[Mathys-Gasnier]

IMO appart from the barrel imports, everything looks good, and looks like a good improvement to code quality, and as it also configures Eslint a bit more, it will allow for contribution to be more within coding standards in the future

[psychlone77]

About the linting and husky parts I believe they are alright, but I am not that experienced with them that much. About the change to barrel imports. I did some research and found that majority of the dev community warns against using barrel imports, even Vite themselves in their documentation. So, only if everyone is on board with that maybe we should move towards it.

An alternative would be to use path aliases, which we can define in the vite.config.ts. So, then we could do imports like,
import SnippetList from '@components/SnippetList'

[saminjay]

I am also against barrel imports. It may be fine for something like components/ui/button and inside button directory you can have some different types of buttons, but not for exporting the whole component directory.

I also think for consistent imports we should have something like @ denoting the src directory and then we go from there, e.g. @/components/ui/button. Just making components, hooks, contexts, etc. available may cause some issues with some package later on.

husky and chunks are a nice addition though. But with chunks It might be better to just add node_modules directory into it rather than cherry picking every packages.

[barrymun]

About the linting and husky parts I believe they are alright, but I am not that experienced with them that much. About the change to barrel imports. I did some research and found that majority of the dev community warns against using barrel imports, even Vite themselves in their documentation. So, only if everyone is on board with that maybe we should move towards it.

An alternative would be to use path aliases, which we can define in the vite.config.ts. So, then we could do imports like, import SnippetList from '@components/SnippetList'

Seems like I'm showing my age with the barrel imports. I've removed them now as they seem to do more harm than good these days.

[psychlone77]

I also think for consistent imports we should have something like @ denoting the src directory and then we go from there, e.g. @/components/ui/button. Just making components, hooks, contexts, etc. available may cause some issues with some package later on.

Should we add path aliases inside this PR, or maybe do it in a new one? @Mathys-Gasnier @saminjay @dostonnabotov

[barrymun]

About the linting and husky parts I believe they are alright, but I am not that experienced with them that much. About the change to barrel imports. I did some research and found that majority of the dev community warns against using barrel imports, even Vite themselves in their documentation. So, only if everyone is on board with that maybe we should move towards it.

An alternative would be to use path aliases, which we can define in the vite.config.ts. So, then we could do imports like, import SnippetList from '@components/SnippetList'

I also think for consistent imports we should have something like @ denoting the src directory and then we go from there, e.g. @/components/ui/button. Just making components, hooks, contexts, etc. available may cause some issues with some package later on.

Should we add path aliases inside this PR, or maybe do it in a new one? @Mathys-Gasnier @saminjay @dostonnabotov

I've just added aliases with a new commit.

[barrymun]

I am also against barrel imports. It may be fine for something like components/ui/button and inside button directory you can have some different types of buttons, but not for exporting the whole component directory.

I also think for consistent imports we should have something like @ denoting the src directory and then we go from there, e.g. @/components/ui/button. Just making components, hooks, contexts, etc. available may cause some issues with some package later on.

husky and chunks are a nice addition though. But with chunks It might be better to just add node_modules directory into it rather than cherry picking every packages.

• barrel imports removed
• now using the @ prefix when importing internal libs
• i wouldn't recommend adding the entire node_modules as this would defeat the purpose. we wouldn't need to add every package when chunking, just the larger ones. Have a look at the attached image; react-syntax-highlighter is quite a large package on its own, whereas react is much smaller:

[Mathys-Gasnier]

For me it looks good now.

[saminjay]

LGTM

[technoph1le]

Awesome work 👍

[psychlone77]

Setting approval for reference