chore: Add ESLint-plugin-ejs-js

[nschonni]

Allow ESLinting of EJS files

[nschonni]

@peterbe think I'm running into a similar oddity that I hit with the flattening of the shell scripts. I can also just run the cleanups and submit them as a first step

[peterbe]

I have an love-hate relationship with this PR. There appears to be a bunch of useful fixes eslint uncovered. But I definitely don't like the added complexity of having to rely on patches and postinstall things. Just because it's possible, doesn't mean we should do it.
If anything, keep the edits that eslint proposes but run that separately. When the 3rd-party tools get fixes, we can put the tools in. Or, can you make the necessary edits so the patches aren't even needed?

[nschonni]

@peterbe I'm going to submit the fixes in separate PRs since it seems like they are OK.

I did submit the hack upstream, but it seems like it's a plugin the author never ended up using. I'll also take a look if the whole parser can be vendored into this project and locally loaded by ESLint

[peterbe]

For the record, once a long time ago, before we could decide between ESLint or TypeScript for all the Node code, I didn't want to wait so I installed eslint locally (one-off) and applied a bunch of fixes. It got use 90% more "correct" but obviously not sustainable.
When I felt the TypeScript momentum started losing steam, that's when I put in a really basic eslint config just to get have something a little big greater than 0.
I still think TypeScript might be best, but it's hard to justify the time-spend. Especially when Yari was so young where you probably want to change directions faster rather than getting the reliability and inertia that TypeScript offers.

[nschonni]

Even for Typescript, the TSLint library ended up porting to a ESLint plugin+parser 😄

[nschonni]

I split out some of the cleanups to separate PRs. After those land, I'll rebase this to do a bigger sweap of the unused variables and redefined variables as new PRs.

[nschonni]

@peterbe so apparently vendoring the plugin into the repo works 😆

[nschonni]

@peterbe I rebased out the template changes since they mostly got spun out to separate PRs

[nschonni]

@escattone fyi, this is the base that I've been using to find the EJS stuff

[nschonni]

Rebased and added in the one-var ignore for now, with a fix for that in #2729

[peterbe]

Drive-by-comment; Is this helping? A lot of the code in the .ejs files is horrible. And we're aware of that. It's old and not very well maintained and honestly, we're hoping it can just last a little bit longer until we get rid of it.

Also, vendoring in code is scary to me. Now it shows up when you search the code and I don't even know what it does to our licensing language when we have to mention that portions are different.

[escattone]

@nschonni I'm sorry for the delay in getting to this. I'm sorry to say that I don't think this is worth adding. I'm sorry because you've done a lot of good work, and I have nothing but respect and admiration for that and your generousity! However, our goal this year is to remove, render-out, or replace all or nearly all of the macros, so I'd rather not invest any more effort and/or code down this path. With that said though, I don't mind that you're using this to create PR's for cleaning-up the current state of our macros (although those PR's will be considered low priority given everything else we have to do). I'm going to close this, but not without admiration for your work!