Dave Herman
Dave Herman
The goal of `do`-expressions is to be a completely transparent construct, as free of caveats as possible. But there may be some syntactic contexts that create trickiness for the semantics....
- The return type is confusing - The name is misleading (it's not doing linking, but rather providing information used later for linking)
The `address` result of the resolve hook, as well as the `address` result of the fetch hook, is polymorphic in the core system. Decide on a format in the browser.
This PR changes the syntax of create-neon to require the user to explicitly specify the Neon project type, either by passing `--lib` or `--app` at the command-line, or otherwise by...
Right now `npm run manual-test` leaves it to a human to do manual testing of the output. Implement an automated test that generates a library and does some basic smoke...
Implement functionality to opt out of generating TS when running create-neon in `--lib` mode.
There's no `"install"` hook for `--app` projects created by the new `create-neon`.
My original design was that shims for third-party binaries would always resolve to a local dependency if it's present (similar to how `npx` and other tools work). My intuition was...
It's come up in some discussions that we might want to consider putting Notion config information in a separate config file (e.g. `my_project/.notionrc` or maybe `my_project/.config/notion/config`), and nudge projects towards...
Do we want some sort of low-level "escape hatch" primitive for letting projects install custom tools that don't install through dependencies. Use cases include things like gcc, Java, phantom, headless...