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.

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.

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.

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

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 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.

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.

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

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.

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:

Awesome work 👍