devinrhode2

in response to https://www.patreon.com/posts/worst-place-to-74324982

ci/cd pipeline stuff is not AS shareable as git hooks. Every ci provider has their own .yml flavor... But even a pre-commit hook can be too late in the process in some situations. I think it'd be really cool to:

1. Have tests/eslint/tsc running while you develop
2. Somehow, have your live reload/dev server "vouch" for certain changes you are staging in git 2.1 Unfortunately this may mean that dirty working directory changes needs to be stashed when you are committing, and then un-stashed when verification succeeds

devinrhode2

Let's imagine you produce an sdk, an npm package named @crazy/foo,

Scenario:

You like monorepos, but you have example apps in separate repos, and those example apps can't be brought into the monorepo for some reason.

You want those example apps to also function as automated tests, and, you want them to be updated in lockstep with @crazy/foo sdk changes.

Devin finds monorepos are always better, and believes it's best to work from first principles to solve any problem you have, in a way that does not involve multiple git repos.

devinrhode2

declare module "redux" {
  /** Replace `compose(a, b, c)` with `(...args)=>a(b(c(...args)))` */
  function compose(
    /** Replace `compose(a, b, c)` with `(...args)=>a(b(c(...args)))` */
    a: never,
    /** Replace `compose(a, b, c)` with `(...args)=>a(b(c(...args)))` */
    b: never,
    /** Replace `compose(a, b, c)` with `(...args)=>a(b(c(...args)))` */
    c: never,
    /** Replace `compose(a, b, c)` with `(...args)=>a(b(c(...args)))` */

devinrhode2

I would DIE for a gui

here's the thing

I create lots of well-sequenced, very intentional commits. They are small and repeatable, so it makes it easy to handle rebase conflicts. Just read commit message, see original diff, and 80-90% of the time I believe anyone should be able to see what the original commit was doing and resolve conflict such that same thing is being accomplished on new base. Almost each commit could be one PR, but maybe sometimes it's better to group few commits into one PR.

I'd like to create a PR stack so that it's easy for others to review my changes, but, I don't want to mess around with git branches locally at all. I'm already a surgeon with rebase.

Ideally, I have a gui tool.

devinrhode2

typescript tsconfig compilerOptions settings ranked by value

devinrhode2

[alias]
  add-archive = "!runit() { REFS_BRANCH=`git branch -a --contains $1 | xargs` && \
                 NEW_REF=`echo refs/archive/$(date '+%Y-%m-%d')/$(git config user.name)/$REFS_BRANCH/$(date '+%s')` && \
                 git update-ref $NEW_REF $1 && \
                 echo consider deleting $REFS_BRANCH && \
                 echo attempting to backup archives && \
                 git push origin refs/archive/*:refs/archive/* && \
                 echo Here is your remote commit ref url && \
                 echo https://github.com/org/repo/commit/$1; }; runit"

devinrhode2

I was getting a seemingly unrelated error trying to git fetch upstream main where upstream was a "public" "git-protocol-url" like git://github.com/foo/bar. That's been deprecated and we need to use plain ssh urls... like git@github.com:foo/bar

What I probably didn't need to do, is blow away all my ssh stuff and start from scratch. But I did that, found out I just needed to update the url syntax from git:// to git@github.com:

However, it seems like converting from id_rsa to id_edXXXXX fixed an error with brew update failing to get latest data from my brew taps.

devinrhode2

Add to your .gitconfig:

[alias]
  breakout-small-pr = "!runit() { CURRENT_BRANCH=`git branch --show-current`; echo checkout $1 && git checkout $1 && echo delete $2 locally && git branch -D $2 || true && echo create fresh $2 && git checkout -b $2 && echo force publish && git publish-branch --force && echo back to original branch && git checkout $CURRENT_BRANCH; }; runit"

Then:

git break<TAB> 
git breakout-small-pr

devinrhode2

const { safeEnv } = require('./src/env')

// Note: NextConfig type allows any keys, so we are plucking the specific keys we want to type-check.
/**
 * @type {Pick<
 *   import('next').NextConfig,
 *   | 'webpack'
 *   | 'env'
 * >}
 */

devinrhode2

/** @type {(...args: any[]) => never} */
const fail = (...args) => {
  console.error(...args)
  throw new Error(args.join(''))
}