Review

[Brandon Kalinowski]

I see you've asked for a review in Gitter. Here are my thoughts.

• Flatten away src and test directories.
• Don't require the package.json in code.
• rulesToRemove/Add.ts would make more sense as a single default object export
• Consider renaming calculate.ts to generate.ts or mod.ts
• I've been using file-level JSDoc comments for Deno code. It's nice to keep that contained as Deno won't download a LICENSE or other metadata file. I'd suggest that at least for the main entrypoint.
• I would avoid top-level code so it is more reusable. What I've been doing in Deno modules is to put the main file contents in a named default export function and then calling that function in the if (import.meta.main) block. That makes it easier to build with.
• One idea is to add a shebang or comment at the top of the main fail to document required deno permission args. Or just place it in the file's JSDoc comment.

[David Else]

Thanks for your awesome suggestions! I have implemented most of them this morning and the new version is now pushed to the repo.

Flatten away src and test directories.
Don't require the package.json in code.
rulesToRemove/Add.ts would make more sense as a single default object export
Consider renaming calculate.ts to generate.ts or mod.ts
I've been using file-level JSDoc comments for Deno code. It's nice to keep that contained as Deno won't download a LICENSE or other metadata file. I'd suggest that at least for the main entrypoint.

• I would avoid top-level code so it is more reusable. What I've been doing in Deno modules is to put the main file contents in a named default export function and then calling that function in the if (import.meta.main) block. That makes it easier to build with.
• One idea is to add a shebang or comment at the top of the main fail to document required deno permission args. Or just place it in the file's JSDoc comment.

I am not a fan of using the default export command, but instead I refactored all the rules that need to be added and removed into one big object. As a bonus I moved the Deno require functionality into that module so everything is a lot clearer in intention and better separated. Was this something like you had in mind? https://github.com/David-Else/automatic-eslint-rule-collection-generator/blob/master/rules.ts

I attempted to add as const to the object to make it immutable, but had type complaints in the main code so put that on hold. Do you think it is worth pursuing?

I had a go at making a shebang, but had a lot of failures getting it to work. I can't find any official info on using a shebang. It would need to work on pc/mac/linux so am a bit concerned about making it incompatible. Do you have any more info or links?

I am interested in your idea of getting rid of all the top level code in respect to the if (import.meta.main), I had a look in your repo but could not find any example. Could you link me one?

Thanks again for this great info. I really appreciate you taking a look, I am self employed and have nobody to do any code reviews other than kind people on forums and chat rooms. Do you think the new refactored version is looking good? I want to add a lot more functionality to it, eventually the user should be able to choose:

• if they want prettier integration
• if they want to use airbnb or some other rules
• if they want to use the ts-eslint rules that need types or not
• if they want to add my additional best practice rules
• other cool stuff I have not thought of yet... any ideas very welcome :)

[Brandon Kalinowski]

• The reason I suggested default export is that it is the same as importing JSON. I know TS has issues with it though. It is odd that as const is not working there, but it is probably not worth pursuing if it complicates things.

• Shebang. Here is a general solution that works with macOS and Linux and any POSIX system. Replace -A with the appropriate flags. I see it mostly as documentation. The user will probably invoke via deno but it does leave the option for a user to chmod +x it and then run it directly.

#!/bin/sh
':' //; exec /usr/bin/env deno -A "$0" "$@"

I'm working on migrating more code to my deno-lib repo. I'll post a link if I remember.

You might want to look at xo if you haven't yet. I haven't used it but it has a similar utility.

Looking good 👍

[David Else]

Thanks! I will let you know when I reach v1.0 and 'go public'.

[Brandon Kalinowski]

You're welcome! Here is an example of a file using the if (import.meta.main) pattern:

https://deno.land/x/lib/kite/examples/dns-example.ts

It's a simple module. Useful on its own but also useful in a larger composition. The implementation of kite.out() will parse Deno args and pass it as an object when it calls the function passed to it. The idea being that any config-generating module can be invoked directly or the exported function could be called in the a larger module's main function. So it could be called like so and the runtypes lib takes care of validating the input:

deno dns-example.ts -f $(jo domain=example.com publicIP=192.168.1.1)

[Brandon Kalinowski]

Here's an idea.
I may give it a stab when I have the time but feel free to give it a try.
It may not work out.

Wire up eslint to support deno-like module resolution.
It could look like something like this:

// .eslintrc.js
const denoConfig = require('denoConfig-v1')
module.exports = denoConfig('https://deno.land/x/lib@vWhatever/eslint.config.js', 'unique-project-id')

Where denoConfig-v1 (or whatever it is) is an npm module that is installed globally. This means the Deno user doesn't need to use npm for eslint beyond installing that one package once. The node module would then invoke the deno binary to fetch the config, install any dependencies of that config at ~/.deno/eslint/unique-project-id and return the result for the module.export. This would allow tools like VSCode eslint extension to resolve config as normal.

I'd really like to see node_modules disappear from project folders.

Or alternatively a fork of @berry/pnpify for Deno package resolution.

[David Else]

Your idea seems cool, but still requires NPM to install eslint.

Snowpack could create the ES Module version of ESlint:

Snowpack re-installs your dependencies as single JS files to a new web_modules/ directory.
↣ Snowpack never touches your source code.
Build your app, import those dependencies via an ESM import, and then run it all in the browser.

https://github.com/pikapkg/snowpack

and they could host it and add it to their list of things for people to discover:

https://www.pika.dev/cdn

These guys have all sorts of module related utilities and services, I don't know if they are into Deno at this point, but I know they would love it:

https://www.pika.dev/

I have not actually tried any of this! I just read their web site.

I thought that Deno was going to get linting built in anyway, so all this is a bit of a moot point?

[Brandon Kalinowski]

That is neat route that I'll look into. But then it is the same thing: snowpack requires npm to install itself. I believe we are a ways away from a JavaScript developer not having to install node and its bundled npm package manager.

I know the Deno team is looking to add a deno lint command but it is going to be an opinionated set of plugins (and specific to Deno) and likely a fork of ESLint. I'm looking for something that is more extensible that could potentially even benefit my non-Deno TypeScript projects.