chore: removing headers
This commit is contained in:
parent
9433c4c8ef
commit
d1ed71eff1
2 changed files with 8 additions and 31 deletions
2
.gitignore
vendored
2
.gitignore
vendored
|
@ -1,3 +1,5 @@
|
||||||
|
releases.yml
|
||||||
|
|
||||||
*~
|
*~
|
||||||
*.epub
|
*.epub
|
||||||
*.mobi
|
*.mobi
|
||||||
|
|
37
src/index.md
37
src/index.md
|
@ -1,47 +1,22 @@
|
||||||
---
|
# Project Layout
|
||||||
title: Project Layout
|
|
||||||
date: 2022-04-01
|
|
||||||
version: 3.0.0
|
|
||||||
categories:
|
|
||||||
- Development
|
|
||||||
tags:
|
|
||||||
- "C#"
|
|
||||||
- Typescript
|
|
||||||
- Rust
|
|
||||||
- asdf
|
|
||||||
- Nix
|
|
||||||
- Semantic Releases
|
|
||||||
- Conventional Commits
|
|
||||||
- Nitride
|
|
||||||
- Webpack
|
|
||||||
- Cake
|
|
||||||
- Lefthook
|
|
||||||
- Husky
|
|
||||||
- Linux
|
|
||||||
- powershell
|
|
||||||
- Windows
|
|
||||||
- GitLab
|
|
||||||
summary: >
|
|
||||||
Organizing project structures when being a polyglot coder.
|
|
||||||
---
|
|
||||||
|
|
||||||
I'm a polyglot programmer. I work in a variety of languages but mostly in [C#](/tags/c-sharp/), [Typescript](/tags/typescript/), and [Rust](/tags/rust/). Every few years, I try a new language to see if I can pick up new ideas or if one "fits" my current mental state better. This is also why I've done a lot dozens of other languages; I would say I know over thirty languages but I'm only a "master" in a handful.
|
I'm a polyglot programmer. I work in a variety of languages but mostly in [C##](/tags/c-sharp/), [Typescript](/tags/typescript/), and [Rust](/tags/rust/). Every few years, I try a new language to see if I can pick up new ideas or if one "fits" my current mental state better. This is also why I've done a lot dozens of other languages; I would say I know over thirty languages but I'm only a "master" in a handful.
|
||||||
|
|
||||||
I also flit from project to project. I have my [writing](/categories/writing/) and games. I have little one-off programs and ones that I hope will become a major thing. But, like everything else in my life, I'm "gloriously unfocused" on my tasks which means I have to minimize the speed that I get into a project.
|
I also flit from project to project. I have my [writing](/categories/writing/) and games. I have little one-off programs and ones that I hope will become a major thing. But, like everything else in my life, I'm "gloriously unfocused" on my tasks which means I have to minimize the speed that I get into a project.
|
||||||
|
|
||||||
# Tools Selection
|
## Tools Selection
|
||||||
|
|
||||||
One of the earliest approaches I had to try getting a proper environment at the per-project level was [asdf](/tags/asdf). It worked out fairly well for a few years, but then I noticed that my various novels and stories were getting fragile. There were limitations that `asdf` couldn't handle easily which meant I needed something more reliable. That led me into [Nix](/tags/nix/) which is my current setup because entering the directory sets up that project's settings while still giving me the reproducibility I need for my novels.
|
One of the earliest approaches I had to try getting a proper environment at the per-project level was [asdf](/tags/asdf). It worked out fairly well for a few years, but then I noticed that my various novels and stories were getting fragile. There were limitations that `asdf` couldn't handle easily which meant I needed something more reliable. That led me into [Nix](/tags/nix/) which is my current setup because entering the directory sets up that project's settings while still giving me the reproducibility I need for my novels.
|
||||||
|
|
||||||
This means that most of my projects now have a `./flake.nix` and a `./flake.lock` in the root level.
|
This means that most of my projects now have a `./flake.nix` and a `./flake.lock` in the root level.
|
||||||
|
|
||||||
# Building, Releasing, and Actions
|
## Building, Releasing, and Actions
|
||||||
|
|
||||||
Because I've fallen in love with [Semantic Releases](/tags/semantic-release/) and [Conventional Commits](/tags/conventional-commits/), a lot of my processes are built around those. In earlier projects, that usually meant that almost every project _also_ included Node in some form so I could use [semantic-release](https://github.com/semantic-release/semantic-release). That also meant I could use `package.json` to handle versioning.
|
Because I've fallen in love with [Semantic Releases](/tags/semantic-release/) and [Conventional Commits](/tags/conventional-commits/), a lot of my processes are built around those. In earlier projects, that usually meant that almost every project _also_ included Node in some form so I could use [semantic-release](https://github.com/semantic-release/semantic-release). That also meant I could use `package.json` to handle versioning.
|
||||||
|
|
||||||
Though, recent thoughts have suggested that I need to break that "one tool fits all" approach. Mostly it came while working on [Nitride](/tags/nitride/) and this website. I found myself trying to have "one build system" to create everything related to the site, including handling Javascript and CSS/SASS. Those are two very complicated projects in C#, so I realize it made sense that instead of creating a Nitride task to call [webpack](/tags/webpack/), I really should just call `webpack` directly. In other words, the [Unix philosophy](https://en.wikipedia.org/wiki/Unix_philosophy).
|
Though, recent thoughts have suggested that I need to break that "one tool fits all" approach. Mostly it came while working on [Nitride](/tags/nitride/) and this website. I found myself trying to have "one build system" to create everything related to the site, including handling Javascript and CSS/SASS. Those are two very complicated projects in C##, so I realize it made sense that instead of creating a Nitride task to call [webpack](/tags/webpack/), I really should just call `webpack` directly. In other words, the [Unix philosophy](https://en.wikipedia.org/wiki/Unix_philosophy).
|
||||||
|
|
||||||
This is where being a polyglot and using different tools comes into play. I have a website that does C#, Typescript, and SASS at the same time. Which one is the "root", which command drives everything? What about a Rust project? Or something else?
|
This is where being a polyglot and using different tools comes into play. I have a website that does C##, Typescript, and SASS at the same time. Which one is the "root", which command drives everything? What about a Rust project? Or something else?
|
||||||
|
|
||||||
That has kind of led me to my current approach. Instead of always packaging Node in my projects, I really should have a standard location to handle the various actions/targets that apply to any project. Right now, that seems to be shell scripts.
|
That has kind of led me to my current approach. Instead of always packaging Node in my projects, I really should have a standard location to handle the various actions/targets that apply to any project. Right now, that seems to be shell scripts.
|
||||||
|
|
||||||
|
|
Loading…
Reference in a new issue