Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support status? #21

Open
davidstosik opened this issue Feb 2, 2021 · 2 comments
Open

Support status? #21

davidstosik opened this issue Feb 2, 2021 · 2 comments

Comments

@davidstosik
Copy link

davidstosik commented Feb 2, 2021

I would like to ask what is the status of the pronto-eslint gem, and whether we have alternatives to running ESLint with Pronto?

I see the gem was updated to run with the latest Pronto release, but two issues were closed yesterday with the following comment:

I think this runner is effectively obsolete as eslintrb hasn't been updated since 2016.

Indeed, eslintrb seems obsolete, but https://github.com/doits/pronto-eslint_npm (also unmaintained :( ) has shown that it is indeed possible to run eslint directly from NPM packages without the need of the eslintrb wrapper.

@ashkulz would @prontolabs be open to reviewing and merging a PR that brings that feature and removes the eslintrb dependency?

@ashkulz
Copy link
Member

ashkulz commented Feb 2, 2021

I didn't realize pronto-eslint_npm is also unmaintained -- I saw it mentioned in one of those issues as an alternative and hence closed them 😞

While I'm not against accepting a PR which does that, I do think that it's not good to change the dependencies so drastically in a minor release -- it'd have to wait for 0.12.0. Alternatively, I think contributing a PR for 0.11.0 support in the above repository would be better. If you're willing to step up as a contributor (I personally don't use eslint), I'm not against officially "adopting" it into this organization.

You might want to ask @doits about their opinion on either option, though 🙂

@doits
Copy link
Contributor

doits commented Feb 2, 2021

It is correct I do not maintain pronto-eslint_npm simply because I do not use pronto anymore. I also think that the idea of using a global npm binary is not up to date with best practices either, where dependencies should be locked/checked into the project using the tool.

IMO an up to date pronto-eslint implementation should be like this:

  • require eslint to be installed into the current project by npm or yarn, so it is a project dependency with an explicit version etc.
  • run eslint in pronto-eslint locally by npx or yarn run (either detect what was used to install eslint automatically or have a config option for it) and parse the output

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants