Understanding the files and remove potentially unnecessary files

[Lenni009]

There are some files that seem a little confusing to me:

• .env.template: Why do we need these .env files in the first place? There's also something in the CI/CD pipeline, but what is the reason for its existence?
• public/github/: This whole folder only has an index.html file which redirects the page. I don't think we need this. I doubt anyone will ever go to nmscd.com/github. And in case they do, they should get the proper 404 page with a link back to the main page.
• public/assets/css/:
  • pico.css, which can be pulled from a CDN or put in via NPM. However, I'm not sure if any changes to this specific file have been made, making it necessary to have it not from the CDN. Pico has a section on customisation on their page: https://picocss.com/docs/customization.html
  • Same goes for simple-grid.css. I don't exactly know what this is, but it sounds like something that can also be pulled from a CDN or NPM.
  • main.css.map I'm sure this has some kind of purpose. But it also looks like this is more something just for the computer, not for humans, and should therefore be handled by the CI/CD or a CDN, not the humans.

We should also minify all the code assets in the CI/CD, I will take care of that. Edit: minify CI/CD step is now on dev

[Khaoz-Topsy]

• The .env.template is an example on what needs to be in the .env file. The .env is used to pass environment variables to the node process without having to actually set them up for the environment 😋.
• public/github/ is a generated folder, it will be removed in my next commit. This is just for making the sharing of links easier, for Github it doesn't really make sense since the url is so short anyway, but for something like a Discord invite it is nice. Like nmsassistant.com/discord
• public/assets/css/
  • pico.css & simple-grid.css I don't like pulling from multiple the CDNs 😂. Cloudflare fast ⚡. It can be slower to pull from multiple CDNs instead of multiple files from one domain. Maybe this would be a good opportunity to combine those into the main.css 😋
  • main.css.map generated file, it helps you know what line a css style comes from in the source code. So even if the main.css is minified, you can still see in the inspector what line the class is on in the source file. This will also be untracked

Sweet 💪. I will join pico and simple-grid into the main.css file 😋

[Lenni009]

Pico can be loaded with NPM and will automatically be included in the build without needing to manually put it into the repo

[Lenni009]

npm install @picocss/pico

It can then be imported in the JS with import '@picocss/pico'; (at least that's what I do when using Vite)

Alternatively we could add a CI/CD step to download it from the CDN at build time

[Khaoz-Topsy]

I am not sure if that will work, we don't have the fancy bundler to handle that 🤔. I think you can import css/scss files from node_modules from inside a scss file 🤔.

Downloading from CDN is definitely possible, I just don't really see the benefit 😅. If those pico css peeps make a change to the styles, there wont be a broken build for breaking changes 😅. At least with npm packages you can pin the versions you hope will be stable and if the break something badly, you will get a broken build (hopefully).

[Lenni009]

Pico V2 will have breaking changes, but we can just stick to a CDN with the V1 version

[Lenni009]

CI/CD action is ready in case you don't get the scss stuff to work

[Khaoz-Topsy]

That is probably true, their repo has been quite lately (https://github.com/picocss/pico). Why do you want to use the file from the CDN though? Love of automation, wanting the latest changes or something else? 😂

I removed the generated files and added pico and simple-grid to the scss folder 😋. I removed your build step to add the nojekyl file in favour of putting the file in the public folder 😝

[Khaoz-Topsy]

Ah I see I need to combine your build steps to the way the scss files are handled 😝

[Lenni009]

Love of automation

Mostly this, but I'm also of the opinion that anything that shouldn't be touched by humans also shouldn't be accessible to humans. The Pico peeps surely have thought something when they made the CSS. So when we don't include the file for the humans, we make sure that it stays functional. Same for .nojekyll. By not including it, we're making sure the humans don't mess with it. It also reduces download size by a whole 0 byte. Actually increases it by a few bytes because of the GitHub action haha. Anyway, the humans can't touch it. And when humans can't mess with something, they can't break it. And if something isn't broken, it most likely works.

[Khaoz-Topsy]

Ah yes, you make good point! Do you want to put those .nojekyll changes and the build step that downloads the css files back? Also you can add yourself to the humans section in site.json 😋

[Lenni009]

So I can now officially say I'm a human? 😛

[Lenni009]

How do you want to handle the SCSS files in the local dev env then? You can't dev without them I think, and I'm not too sure how to properly get them downloaded to your machine... Especially since Windows and Linux have different commands. I tried using CURL in Windows. In CMD, it just gives an error. In Powershell, it spits out the HTTP response, but only 8 lines of the actual SCSS content. The same command would've worked perfectly fine in Linux.

[Lenni009]

I think adding automatic file downloads to the setup process on the dev side is a big pain (on the other hand it's super easy for the CI/CD). I therefore will only put the nojekyll file into the pipeline again.

[Khaoz-Topsy]

I added some automation for the downloading of third party scss files. The simple grid css file comes with a bunch of styles for the body that I don't want, so skipped it and only the pico css is automated for now 😝