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## Future Goals
1. Support Deno.json to get compiler options.1. Handle mapping from remote specifiers to bare specifiers and transforming them in the file.1. Handle dynamic imports (at least ones that are statically analyzable and maybe warn on others)1. Support creating or modifying a package.json and using that for publish.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.