-
Notifications
You must be signed in to change notification settings - Fork 5.9k
Description
Due to issue #19826, I'm writing this to address what seems to be a common problem with tools incompatible with deno. A lot of CLIs developed by dev-tools, frameworks, and dev-management teams that are aimed at DX functionalities like init, migrations, testing, upgrades, debug environment setup and so forth assume the existence of a package.json.
The fact that a very trendy tool like drizzle for so long has one of its main value propositions not working on deno because of that is a problem big enough that it may turn people away from the deno runtime in general. I'm working on patching the dev cli of the wonderful trigger.dev where (unlike the case with drizzle-kit) the cli is a must to effectively use the platform.
The trigger libraries, including their framework integrations, like the drizzle libs, all work with the npm specifier. Just the assumption of a package.json holds off deno compatibility in trigger.dev for quite a long time. unlike trigger drizzle-kit is not open-source so it can not be patched by the community.
I think this should probably be addressed in a more general way. One idea could be to provide cli developers some form of convenient encapsulation over runtime config. This way it is easy to patch tools (and also develop them runtime agnostic from the get-go) since you won't need to open the deno docs (and potentially other js runtimes' docs if those would also be supported).
something like:
1. `runtime.installedPackages(projectRoot): {packageName, repository, version}[]`, taken from package.json / deno.json(c) +import_map)
2. `runtime.installPackage`
3. `runtime.updatePackage`
4. `runtime.`[checkUpdates](https://www.npmjs.com/package/npm-check-updates)(projectRoot)
5. `runtime.userConfig` any user keys in package.json / deno.json
6. `runtime.scripts` returns runtime.scripts (add, replace, run)
This I hope can encourage developers to build more cross-runtime dev tools.