Hey @lukeed, I find myself revisiting this module, because I'm part way towards [adding ESM support to yargs](https://github.com/yargs/yargs/issues/1706).
**I have a feature request ...**
Would you be open to using dependency injection in this library, similar to what I've done in [yargs-parser](https://github.com/yargs/yargs-parser/blob/master/deno.ts), to target Deno as well?
The main advantage I see to this is that it helps isolate the Node-specific APIs you're using, making it easier to target a variety of other platforms.
Hey :) welcome back, haha
Would a separate entry work? These are bad names, but something like `escalade/deno` or `escalade/shim`. I can add this without being breaking, since it's opt in.
Personally I've been waiting on Deno's [import maps](https://deno.land/manual/linking_to_external_code/import_maps), or a "deno" package key to land, or for Deno itself to find another way to get Node natives to resolve without needing to import all of `std/module` into scope.
How is Deno able to resolve that entry file? Is it purely just through URL access?
> Would a separate entry work? These are bad names, but something like escalade/deno or escalade/shim. I can add this without being breaking, since it's opt in.
> How is Deno able to resolve that entry file? Is it purely just through URL access?
Exposing a separate entry point like `./deno.js` or `./deno.ts` (if you're so inclined) seems to work quite well. Then you can toss the library up [here](https://deno.land/x) which requires:
1. an initial OAuth authentication step/creation of WebHook.
2. the tagging of releases (_which you already are_).
A consuming library can then do this
```ts
// the Deno.land registry URL could be used below alternatively:
import parser from "https://github.com/yargs/yargs-parser/raw/deno/deno.ts";
const argv = parser('--foo=99 --bar=9987930', {
string: ['bar']
})
console.log(argv)
```
---
In the case of a library as simple as this, the main work would be isolating the fs operations:
`fs.readdir` -> [Deno.readDir](https://doc.deno.land/https/github.com/denoland/deno/releases/latest/download/lib.deno.d.ts#Deno.readDir).
`fs.stat` -> [Deno.stat](https://doc.deno.land/https/github.com/denoland/deno/releases/latest/download/lib.deno.d.ts#Deno.stat).
etc.
Cool! I'm glad the separate-file route is an option. My weekends are away from the computer lately, so I'll have this done by Monday at the latest. Does Deno support `@next` tags or will I have to risk extra versions if I get the upload wrong, haha
> Does Deno support @next tags or will I have to risk extra versions if I get the upload wrong, haha
I believe right now it just makes whatever tag was most recently published the most recent version.
This isn't great if there's a build step ... for yargs-parser, I have a GitHub action that creates a special deno tag whenever a release happens:
https://github.com/yargs/yargs-parser/blob/master/.github/workflows/release-please.yml#L24
Ok, everything seems to work locally @bcoe
When you get a chance, can you verify that things work as expected on your end too? If they do, I'll publish `3.1.0` and consider this done :)
This is the test script I used as a sanity check:
```ts
import escalade from 'https://deno.land/x/escalade/sync.ts';
let output = escalade('.', (dir, list) => {
console.log('~> dir', dir);
console.log('~> list', list);
if (list.includes('package.json')) return 'package.json';
});
console.log('OUTPUT', output);
```
```sh
$ deno run --allow-read deno/test.ts
```
@lukeed things seem to be working great:
```typescript
// TODO: we should think of a way to support this functionality
Deno.test('guesses version # based on package.json', () => {
let output: string|null = null
Yargs()
.parse('--version', (_err: Error, argv: Arguments, _output: string) => {
output = _output
})
assertMatch('' + output, /[0-9]+\.[0-9]+\.[0-9]+/)
})
```