123456789101112131415161718192021222324
- add `--version`/`-v` argument- tests for CLI- tests for multiple deno-types for the same module pointing at different .d.ts files (error)- Handle deno-types when it references a `.ts` file (maybe transform the .ts file to .js?)- Maybe the ability to skip using the TypeScript compiler (useful for people with only JS projects)- When working on transforms, warn when a version in package.json or transforms doesn't match remote specifier- Support multiple entrypoints with a default entrypoint used in package.json (the first one)- Store wasm file encoded within js module## Future Goals
1. Support Deno.json to get compiler options.1. Handle dynamic imports (at least ones that are statically analyzable and maybe warn on others)1. Remove `@deno-types` and type reference directive comments. Currently leaves them as-is, but better to remove them in case the npm package gets re-consumed in Deno.
Notes from Kitson:
- We would need to rewrite triple slash references- We might need to deal with the types in the tsconfig.json- How do we handle remote URLs, data URLs and blob dynamic imports?  - David: Just changed it to download everything for now, but in the future we can implement remote URL -> bare specifier mapping. Ideally this will be automatic, but in some cases the user will need to specify a bare specifier to use.  - David: We could probably output data URLs to a file.  - David: Blob dynamic imports... I'm not sure. Dynamic imports will be a problem if they're not statically analyzable, but we can warn the user about that when it happens.