> > scripts, doesn't matter since all Deno projects have the same tools built-in (benchmarker, bundler, compiler, formatted, linter, task runner, test runner, etc...)
>
> AND...you therefore can't do anything outside of the box in a well-defined way. Oops.
>
> Example: How do I run just the main server and not a worker? How do I seed the database?
That doesn't really make sense. If you're trying to do anything in a well-defined way, you're going to need a box. The box is the definition.
------------------------------------------------------------------------------------------------
> > dependencies doesn't matter anywhere near as much because Deno comes with a standard library
>
> Sigh. Yeah. Really. You said that.
>
> OK, using the standard library, please: [...]
I'm not going to be able to do these in a comment here, but I can briefly tell you how I would go about doing them.
> - Parse Excel files, modify them, and rewrite them to disk.
Use streams API to create a pipeline (input -> modify -> output).
If by Excel files you mean CSVs, then I can stream the whole thing, making modifications and saving while I'm still streaming in the file.
If by Excel files you mean an xlsx file, then I tweak the pipeline to (input -> unzip -> modify -> rezip -> output).
> - Load and modify a PNG and write it out as a JPG. Be sure you scale it down using a Lanczos kernel.
First I'd make sure I have the encoder and decoder settled. If you have a specific encoder in mind (e.g. ImageMagick + specific settings) then you can box that up by compiling it to web assembly. If you don't have a specific encoder in mind then it doesn't really matter what you use. If you have a specific encoder in mind, then same thing. If you don't, you can always use the JS standard Canvas API which you can load an image into then pull out raw pixel info.
If you want to do the whole thing from scratch, you can do it like the Excel way and create a pipeline using the streams API and TypedArrays.
------------------------------------------------------------------------------------------------
> > eslint doesn't matter since deno has a linter
> One of the most powerful eslint rules for TypeScript is the detection of dangling promises. A quick glance at the deno lint rules doesn't see anything that will handle this critical lint rule.
>
> And OOPS, adding eslint to the project in a standardized way isn't possible because there's no package.json!
Linting for floating promises is tricky to accomplish (ESLint doesn't get it quite right).
Depending on the code, you can get stuck in the halting problem. To solve it correctly, you need to write a compiler/solver that has access to the relevant type information.
This is something that the typescript project itself has been investigating and once solved would be added as another strict rule (e.g. noImplicitOverride, etc...).
If you don't care about correctness and want any heuristic solution, then use any heuristic solution.