refactor: move styles to assets

[preschian]

Thank you for your contribution to the KodaDot - One Stop Shop for Polkadot NFTs.

👇 __ Let's make a quick check before the contribution.

PR Type

• Bugfix
• Feature
• Refactoring

Context

• Hopefully can reduce total files changed between main and nuxt branch

Did your issue had any of the "$" label on it?

• My DOT address: Payout

Screenshot 📸

• My fix has changed UI

Copilot Summary

🤖 Generated by Copilot at b733447

Moved all styles files to the assets folder and updated the import path for the variables file. This refactor aimed to improve the structure and organization of the project.

🤖 Generated by Copilot at b733447

styles moved to assets
refactor for clarity
autumn leaves fall gently

[netlify]

✅ Deploy Preview for koda-canary ready!

Name	Link
🔨 Latest commit	2d131a7
🔍 Latest deploy log	https://app.netlify.com/sites/koda-canary/deploys/6515105d3639ca0009a8d8ed
😎 Deploy Preview	https://deploy-preview-7394--koda-canary.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.

[reviewpad]

AI-Generated Summary: This pull request involves comprehensive restructuring of the project's directory for style assets, more specifically moving style related files from the 'styles' directory to 'assets/styles'. Various vue and scss component files have their import paths updated to reflect this change in the project directory structure. The update chiefly impacts the import statements for 'variables' and certain component style files which have been shifted to the 'assets/styles/abstracts' and 'assets/styles/components' directory from 'styles/abstracts' and 'styles/components' respectively. In files like 'ListingCartModal.vue', 'GalleryItemTransfer.vue', 'CollectionInfo.vue', 'UnlockableCollectionBanner.vue' and many others, a single line import update can be seen from '@/styles/abstracts/variables' to '@/assets/styles/abstracts/variables'. Other files like '_popup.scss', '_search.scss', and '_carousel.scss', were merely moved to the 'assets/styles/components' directory without any content modifications. The 'nuxt.config.js' file also sees an adjustment in the global CSS file path from 'styles/index.scss' to '@/assets/styles/index.scss'. It is essential to inspect each component for potential style-related issues due to this large-scale modification.

[reviewpad]

Reviewpad Report

⚠️ Warnings

• Please link an issue to the pull request

[codeclimate]

Code Climate has analyzed commit 2d131a7 and detected 0 issues on this pull request.

View more on Code Climate.

[sonarcloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

No Coverage information
0.0% Duplication

[roiLeo]

why?

[preschian]

why?

1. I'm aware that this PR does not fix the blocked issue. But, fewer files changed in here main...nuxt === easier to review once ready to merge nuxt to main
2. If the API/code usage is the same between nuxt2 and nuxt3, there is no need to create two branches targeting nuxt2 and nuxt3. For example:
   1. Error money component. While creating this PR chore: fix warning on money and dropdown #7383, I just realized the money component on nuxt3 is already fixed. The error happens on both nuxt2 and nuxt3. So, make one PR targeting nuxt2, and then on the nuxt branch, just sync it with the main branch
   2. Adjust fa sharp icon as default. I created 2 PR, targeting [nuxt2](chore: fa sharp regular as default icon)chore: fa sharp regular as default icon #7302 and nuxt3. It should be easier to create 1 PR targeting the nuxt2 branch and then just sync it with main in the nuxt branch
   3. more context for this PR or this PR. Let's say another contributor added some files to static/some-logo.png or styles/component/some-component.scss in the nuxt2 app. We don't need to update those files to public/some-logo.png or assets/styles/component/some-component.scss once we sync the nuxt branch with the main branch
3. We can skip No. 2 if the API/code usage differs. It is expected to be unavoidable. Such as:
   1. change $apollo to useAsyncQuery or something like that in the new API
   2. change $seoMeta to useHead()
   3. etc... some breaking API