We Keep Coding

How could I show current GIT branch in my Vue 3 Web application

I like to have a visual cue of the current GIT branch I am working on and have that set up in my IDE (I currently use VIM but I know VSCode also does this). I like/need it so much that I would really also like to see it in my development build when serving locally.
I currently do this manually with a label that I update by hand each time I create a new branch to work on. However, I often forget to do this and subsequently confuse myself.
I'm wondering whether it would be possible to pull this information from GIT and show it in my UI in the same way VSCode does?
Specifically I am using Vue 3 and Typescript but I guess that is not super relevant to the general problem.
Anyone have a feel of how you would do this?

If you are using Webpack as a bundler, there is a git-commit-info-webpack-plugin which can write some Git info (branch name, last commit date/hash/author) into a json file on each build.
Just import the json file into your app and use it....

How to tell npm to build module on install with the parent project's dependencies?

I would like to get an explanation about the way npm modules getting build on install, I'll give an example:
When I'm taking a look on the material-ui npm module sources on GitHub, There's sources but there's no built files, when I take a look on my project node_modules/material-ui directory I can see that the directory contain only the built files (es5, uglify).
I'm trying to understand how that magic happens? I see that there's build script inside the package.json but there's nothing that tell npm to run it on install, what am I missing?
Thanks

Usually modules don't get built on the client's machine, because that would take additional time and might fail because they are using an older version of Node.js that doesn't support the build tools, and of course the build tools would need to be installed as well, which would make the process even longer. Instead you build it before publishing. What is on GitHub is different from what is actually published to the npm registry. Most modules don't check in the built sources into GitHub (although some people prefer to).
Presumably material-ui does this process manually and just publishes the built sources, as seen in Unpkg - material-ui.
Some other packages like redux use a prepublish hook, which builds the necessary sources just before it gets published when running npm publish (Redux prepublish hook), which reflects the published package as you can see in Unpkg - Redux. It's pretty close to the original source on GitHub but only contains the relevant files, including built files that are in its .gitignore file. Because a lot of files are unnecessary to be published (e.g. the test directory, rollup.config.js etc.) and would only take up space on the client, you can specify files in package.json to only publish the listed files (Redux files).
You just happened to have picked a quite confusing package with material-ui when it comes to publishing, whereas redux is a lot easier to understand.

Modify (patch) meteor packages in a clean way - Meteor

I am currently using the accounts-ui-bootstrap-3-blaze package in my Meteor application and I want to modify the login_buttons_dropdown.html file to just add an additional button in the drop down.
How can I patch this package in a 'clean' way?
I already downloaded the package and embedded it manually via the smart.json file, but then I was not able to perform an automatic update via mrt.
Any help would be greatly appreciated.

If it's only for the purposes of a single project then the easiest way would be not to use mrt at all, but put the package source code to the packages directory manually. You will also have to update the .meteor/packages file by yourself. One advantage of this solutions is that any updates to the package source code will be automatically detected by Meteor, so you can take advantage of the hot-code-push feature. This is particularly convenient while in the development process.
If you're planning to re-use your patches in other projects, then I would recommend forking the original repository. It should be quite easy as it will be probably hosted on github. You don't need to publish a package on the atmosphere to be able to install it with mrt command. The only thing you need to do is tell the meteorite to look for this particular package in your custom github repository, so:
"accounts-ui-bootstrap-3-blaze": {
"git": "https://github.com/yourUsername/accounts-ui-bootstrap-3-blaze.git"
}
in your smart.json and you are good to go.

Is there a way to have different JavaScript library versions on different branches in Git?

I am trying to upgrade a repo that currently uses a library that is in version 3. I want to be able to create a branch (BranchB) that is specific to updating this library to version 4. So I tried changing the package.json on BranchB to use v4 and did an npm install in order to get the correct version on this new branch.
I run the tests and they fail. Perfect.
Now when I switch back to master, I would prefer that the library version being used is set back to v3. Is there a Git workflow to make this possible? Or will I keep having to npm install every time I want the appropriate branch to have the correct corresponding library versions?

One possible strategy, albeit a bit clunky, is to clone the repo twice to different folders - one with the older library, one with the newer. Then just pretend that you've got split personality and edit the projects as two different programmers :)
As I said, it's clunky but it's better than constantly installing the libraries.

What is the perfect workflow to work on A, B & C in parallel where A depends on B and B on C?

I wonder what is the perfect workflow if one needs to work on project A, B and C in parallel where A depends on B and B depends on C.
Currently I have everything in one repository which speeded up the early development. So my working directory looks like this:
/A/
/A/B
/A/B/C
So A is the project that is driving the development but it also means B and C are in parallel evolvement.
However, I want to release the projects B and C individually as well as they are quite useful for others.
However, I'm torn on how to do this without ruining my development speed. npm is great for distribution and dependency management but during development you definitely don't want to move temporally versions across the internet just to get the files to update in a different folder on your machine :)
On the other hand you also don't want to manually copy them over. Heck, all this I have to switch directories to work on B and now copy it over to /A/B is scary and seems error prone.
So, git submodule seemed like the answer as it's essentially enabling exactly that: You would keep your directory layout just as it is. Then when you make changes to files in B you can directly test them out in A without having to copy something over. And when you think it's ready you can just commit and push from the three different folders. Everything goes into three different repositories automatically. Seems like heaven yet everybody hates git submodule for various reasons.
I have pretty much the same problem when working on grunt plugins. I have the grunt plugin in it's own repository and then when I'm working on it I have to copy it over in one of the projects where I use it to drive the development. And then at the end of the day I copy it back to the grunt plugin working directory, make commits and push them. Thank god, I'm not the author of thousands of grunt plugins so I can deal with that but for this project I'm currently working on, I would definitely like to find a better solution.
So I wonder, what is the answer?

Note that Git submodules point to a specific version of the external repository, i.e. to a specific commit.
To update all Git submodules to the latest version, you’d still have to run a command:
git submodule foreach git pull origin master
Depending on your situation, you could possibly use npm instead of Git submodules. In that case, you simply list your dependencies in package.json, then run npm install in the root of the repository to fetch them. If a dependency is updated and a new version is published, you just run npm update again and it will match the version requirements set in the package.json file. You could also use npm to point to a specific commit, much like how Git submodules work:
{
"devDependencies": {
"dependency-a": "git://github.com/the-user-name/the-project-name.git#b3c24169432a924d05020c85f852d4a1736e66d4"
}
}
Or, if you want to use a bleeding edge version of a dependency, like the master branch of a given Git repository, you could use:
{
"devDependencies": {
"dependency-a": "git://github.com/the-user-name/the-project-name.git#master"
}
}

I've tried all number of these workflows and have decided that git submodules are not the answer. The main reason for me being that they couple projects together at a scm level and it is not intuitive as to where exactly in the revision history this coupling happens. Especially in a detached head scenario.
I rely on npm for depency managment with a combination of npm link and git URLs. npm link is great when I want to test something locally. git URLs are perfect to resolve dependencies during pull requests. Eventually I always want a published module with a version number I can match to a git tag for future reference and issue tracking. I use npm version to do this in one step. Allows for projects to depend on each other at varying levels of coupling during my development cycle.

Would using git subtree be the answer here? This article Alternatives To Git Submodule: Git Subtree did a good job explaining the pros and cons of using git subtree versus git submodules.