December 10th, 2021 | notes | kipras melnikovas

(hidden) k0b-3Uk_N #[[(hidden) S-ygYfi0j]]
- (hidden) MfgmtqtJX [[(hidden) 8CNrCRDNZ]]
  - {{[[TODO]]}} (hidden) QZA7AdpRi #watch
    - (hidden) GzTV4MMOm
  - (hidden) 3QGdI8brt
- (hidden) WouVxm0oP
  - (hidden) 3OIVF9MZX
  - {{[[TODO]]}} (hidden) J6lHUcwH- [[(hidden) X7oZG5qJs]] [[(hidden) 4fWGWPmjq]]
  - (hidden) ZtYkxog1F
- {{[[TODO]]}} (hidden) 1vCCNEPFw [[(hidden) pHco5hQZn]]
- (hidden) 74rpVxiTE
- [[codemods]]
  - {{[[DONE]]}} finish refactoring so that i can finally start doing new stuff + to get the reviews moving
  - {{[[DONE]]}} think of how to "fix" the jira stuff
  - {{[[TODO]]}} prepare for [[(hidden) 0hZvdpkVn]]
    - maybe "how codemods work - from first principles", or "how codemods & jscodeshift work - from the very basics"
    - {{[[DONE]]}} maybe reach out to our production team / [[(hidden) _RMDwHiKR]] & ask for a good mic? not necessary, but would be good
      - {{[[DONE]]}} idk who's @ production team so just reach out to [[(hidden) _RMDwHiKR]]
      - {{[[DONE]]}} get response
      - {{[[TODO]]}} also borrow/buy an additional adapter for the macbook (tho i could use my linux setup just as well for this)
    - {{[[TODO]]}} explain how a compiler (or interpreter) sees your program
      - high level summary of the below:
        
        begin @ ast explorer
        
        explain what we'll do today
        
        we'll try to understand how codemods work
        
        we'll write our own codemod
        
        we'll learn how to use jscodeshift a bit
        
        we'll see some real-world examples of codemods
        
        we'll explore extra resources
        
        https://notes.kipras.org/codemods.html
        
        https://github.com/facebook/jscodeshift
        
        https://github.com/reactjs/react-codemod
        
        https://github.com/mui-org/material-ui/tree/master/packages/mui-codemod
        
        https://github.com/CodeshiftCommunity/CodeshiftCommunity
        
        https://www.codeshiftcommunity.com/
        
        https://github.com/dsherret/ts-morph
        
        .
        
        a codemod is just code that modifies other code
        
        "but what __is__ code?"
        
        it's just text!
        
        explore ast explorer
        
        select parser to flow
        
        write some code
        
        why should i care? because we'll want to modify it!
        
        doing it hardcore raw (eg regex), vs using existing libraries (eg jscodeshift from ex-fb guy)
        
        ast explorer
        
        come back to the same fn we wrote
        
        modify the greeting
        
        explain that this is what codemods are fundamentally about
        
        ast explorer
        
        another, similar fn
        
        showcase filtering (basic)
        
        showcase filtering (built-in)
        
        showcase parent finding `.closest()`
        
        showcase `.check()`ing
        
        again, double down that this is how starting to add tiny bits of extra complexity might look like, but the fundamentals stay the same.
        
        show external resources
        
        explore some of our own codemods, show patterns
        
        do overview that it's often not only code, but people, organizational problems as well
        
        fin
      - show an example of writing some basic code in [[(hidden) eBB7dPivO]] and how the AST starts looking like
      - there are a few things at play - the parser, and then the "writer" which takes the parsed input, and produces the new output
      - ...now we want to somehow modify this code. so between the parsing and the writing (when we have the parsed code in the AST form, but we haven't written it to a file yet), we want to somehow modify the AST so that when we write in to the file, it will contain our modifications
      - so you need to modify the AST.
      - you __could__ write your own library to walk thru the AST, detect what kind of tokens (types of code) there are, but people have implemented this a long time ago - here comes jscodeshift.
      - it's a tool that allows you to easily find ~~tokens~~ nodes, to find nodes somehow related to them (searching in general), and then to check the node's properties, and then to modify either the node's properties, or the node itself (i.e. remove it, replace it w/ a different node, move it up or down or somewhere else around), and even create new nodes.
        
        {{[[TODO]]}} do a better explanation of what a token is, both conceptually and w/ an example
        
        {{[[TODO]]}} same w/ a node
      - show an example of the transformer (write something simple yourself first)
        
```javascript export const parser = 'flow' export default function transformer(file, api) { const j = api.jscodeshift; // would it make sense to call `src` as `ast` instead? const src = j(file.source) return src.toSource(); } ```

be careful to __not__ over-simplify.

maybe if we're fast, we can cover even the basics, but not be too boring for more experienced folks.

also, gotta practice so that i don't ever get confused or dont know the solution immediately so that others dont have to waste time w/ me debugging

{{[[TODO]]}} heh, maybe we can use actually component names? though meh, would involve more context, having simple js function w/o anything more to think about seems better

```javascript export const parser = 'flow' export default function transformer(file, api) { const j = api.jscodeshift; const ast = j(file.source) ast .find(j.FunctionDeclaration, { id: { name: "greeting" } }) .forEach(path => { const { node } = path; console.log("node", node); node.id.name = "sayHi"; }) return ast.toSource(); } ```
        
        explain why we use .find instead of filtering in the forEach - because you can chain multiple .find's and it's just easier + more efficient + becomes clearer for what you're looking for from the very beginning
      - after that, explain that a "codemod" is just a collection of transforms that we combine and run one after another.
        
        everything else is just more complexity, more advanced scenarios. but fundamentally, this is what a codemod is.
      - consider - should we write a jsx transformer as well?
        
        probably yes, and just mention that one can skip to the next part of the video if they aren't interested
      - [[hindsight bias (in retrospect, it looks simpler than it actually was)]]
        
        also mention that there are nuances, and to not expect everything to necessarily go smooth the first time - leave time for uncertainty:D
        
        e.g. wrapping in JSXExpressionContainer
        
        other challenges outside of the actual writing of the codemod - getting the "from/to" mappings if you're not familiar w/ the library, or e.g. if a designer decided them and has e.g. a spreadsheet that you'll need to parse, etc -- it's not all just writing of code, it involves other problems as well:D
        
        then ofc the infra needed to run the codemods.
        
        could mention [[(hidden) C5ze2tqB8]] ofc, and that's where we started, but atm we've diverged so much from them, that we have somewhat different namings & structure & style as well
        
        (hidden) WrCq5CZwG #[[(hidden) 7c2C8PgIV]]
        
        (hidden) RjxKGQQrP
        
        (hidden) sxwZl0gqY
      - also mention that a transform should do 1 thing and do it well, and for separate things you should have separate transforms, and combine them in the codemod.
        
        but also mention that if the specific thing you're doing is the same, and the only thing that differs is the data (e.g. the component's name, or the attribute's name, or the attributes value / from-to mapping), then you can abstract it and just take in a "config" that has these - thus now you
- (hidden) VyMFgBQSz
(hidden) AtPY3OhjQ
(hidden) nZtElhmt0
[[roam-traverse-graph]] [[export-html-pages]]
- {{[[TODO]]}} "public-recursive" tag - public on itself, and all of it's children. if a page is marked as "public-recursive" on first-level child block w/o any children & only it (exactly how public global tags work now), it should also make itself and it's children public __when it is mentioned__.
  - hmm. but now think about block mentions. if a block contains a mention to another block that has this recursive tag, then does that mention make the block who mentioned it also recursively public? kinda unwanted!
  - maybe we need separate ones for:
    - "public when mentioned as a linked reference" (which would normally be the default, or so i though, until i realised that e.g. ppl names are not very good to be public by default, and well that the default wasn't very good, so we changed it)
    - "public, as in make the page & it's children public, but nothing else",
    - "public recursive" - make
      - wait. maybe:
        
        "public recursive _marker_" - do not make itself's children public, but make itself's title, and all _direct_ mentions of it public + their children.
        
        same as [1], but recursive
        
        [1] ((bzzfvHav8))
        
        "public
  - hmm, now that i think of it, seems like this "public or not, when mentioned" will always be a problem w/o a good default. instead, it seems like it should be something you do directly. e.g., have a triple `[]` mean a public linked reference (since more effort, less likely to accidentally make something public), and double `[]` - same as is now. could do this myself unofficially, the only problem is that the roam search breaks - roam starts looking for a `[]` in pages' titles, but ofc they don't have this, and so the completion list ends up empty, which sucks big time!
    - {{[[TODO]]}} create an issue in #roam to change the behavior (ofc explain why i need this)
- {{[[TODO]]}} as for security, i keep thinking about: should i include the security info in the default setup when explaining how to use the plugin in e.g. [[github actions]], or should i put it afterwards
  - i think the defaults matter. and so i should definitely put it in the default setup, because that's what everyone's gonna do.
  - the easiest thing to do, for starters, is to fork the repository and use the fork, instead of the main repo, as the source of the plugin(s)
    - updating is very easy. `fetch upstream` button available in [[github]] right next to the latest commit's info
    - {{[[TODO]]}} the repo could have security tests that should pass before each plugin run, so that in case we push to master and accidently get something messed up and a person also fetches the update at that time - they would immediately see the problem, instead of getting pwn'd.
    - {{[[TODO]]}} #[[(hidden) jOMmlCP4S]] `git-rebase -i` right inside [[github]]'s PR UI lmao
- {{[[DONE]]}} simple docs for the plugin (just some notes + link to public notes on it)
(hidden) L8K_eX01k
(hidden) C8fTkbGQM #[[(hidden) 7-F05odqi]] #vscode
- {{[[TODO]]}} (hidden) i43eZWKPK
  - {{[[TODO]]}} (hidden) JyrQ4MCgi
    - {{[[TODO]]}} (hidden) wDgTZv0Vt
      - {{[[TODO]]}} (hidden) xU83AFJix
    - (hidden) UJLh7w6Bd
  - related: [[git-stacked-rebase]]
    - {{[[TODO]]}} automatic "refactor" command - `git blame HEAD` for each line to find what commit needs to be fixed up into, commit, prepare git-rebase-todo w/ the `fixup` commands ready
      - maybe not everything is `fixup` tho so might want to be able to review the changes comfortably b4 creating the fixups
    - {{[[TODO]]}} we could very well, after `apply`, have `check`, which would go from 1st branch to last, and could have a sub-command of `check` that would show the diff in the branch - same as we have the alias `sod`
      - {{[[TODO]]}} on the alias - would be good to have it, but also a separate alias that would show only that branch's diff, __without__ the changes included from previous branches
      - {{[[TODO]]}} `next` and `prev` to switch between branches / diffs
        
        yep seems to make sense.
        
        {{[[TODO]]}} could even have the `current` stacked rebase ref, so that you don't even need to specify the branch you're on & the branch you're rebasing on top of, and could do just `git stacked-rebase prev` & `git stacked-rebase next` w/o any shenaningans
        
        re: ((3l52fL6rH))
        
        at this point, it indeed does look like `stacked-diffs` is becoming an actual concept
  - (hidden) KQB9XVZnD
- (hidden) EJDcO_8d_
(hidden) qepI5ZeuE
(hidden) nSGpZkB2e
- (hidden) Iy-0YIPql
- (hidden) XyjC-qXbH
(hidden) 3Acxp13F3
(hidden) 7mNonNGBb
(hidden) SXxlm30xa

words:	1823 + 48 = 1871
last update: