✅ Deploy Preview forquicksnip ready!

Name	Link
🔨 Latest commit	ea49c91
🔍 Latest deploy log	https://app.netlify.com/sites/quicksnip/deploys/677808e6dd9f3b00083b31e8
😎 Deploy Preview	https://deploy-preview-154--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 yourNetlify site configuration.

Instead of ignoring thecomponents/ui folder, we could runnpm run lint -- --fix to fix those issues. Since those files are also technically part of the codebase which could be modified in the future, better to have those files also kept properly.

Instead of ignoring thecomponents/ui folder, we could runnpm run lint -- --fix to fix those issues. Since those files are also technically part of the codebase which could be modified in the future, better to have those files also kept properly.

agree , but it would literally just be an overkill , to keep running it each and every time to fix the linting errors for the already pre built components
i would recommend two option here ,
-> ignore the components/ui folder which has all the pre-built shad-cn components which might hardly require some changes

-> just add the npm run lint fix command to the workflow file

I'm too thinking we should ignore the components from shad-cn, it will just be a pain to reformat them each time.

agree , but it would literally just be an overkill , to keep running it each and every time to fix the linting errors for the already pre built components.
i would recommend two option here ,
-> ignore the components/ui folder which has all the pre-built shad-cn components which might hardly require some changes
-> just add the npm run lint fix command to the workflow file

We will only have to fix the linting errors once when someone adds a new 'shadcn component' to the project. Since 'shadcn' components is still someone else' s code and we are technically just copy pasting the components into the project, we should still make sure that code follows the project's eslint rules.

Runningnpm run lint -- --fix is an option, but might introduce changes which the person who made the commit might not have expected. It's better for the build to fail and show where error was, instead of it automatically making changes.

any updates of still using shadcn?

Fix conflicts and errors of your PR before we review again

@Mathys-Gasnier I think we should probably open up another MR for this. It is blocking a lot of other developers from contributing.