Proposal: Move the "feature" of standardx into standard

[Raynos]

It's difficult & time consuming to maintain two npm packages ( https://github.com/standard/standardx and https://github.com/standard/standard ).

Standardx has some open issues that we don't have much bandwidth for ( standard/standardx#27 & standard/standardx#7 ).

What do you think about taking the standardx features and moving them into standard itself so that it's simpler to maintain both packages. The amount of code in standardx is pretty small.

[Raynos]

cc @feross @LinusU

[LinusU]

Ultimately up to @feross, I'm okay with it ☺️

[JeffSpies]

Speaking as a user that is currently blocked from using Standard at all because of TS compatibility issues, if this is better for the respective maintainers, this does seem ideal for the users.

Thanks for all the hard work!

[LinusU]

@JeffSpies for TypeScript, I think that use case is better served by ts-standard, until we potentially can merge that into standard. Have you tried ts-standard? ☺️

[JeffSpies]

I got your message about ts-standard in another thread; I'll give it a try. Should we submit PRs to update docs/readmes with this recommendation?

I'll be happy with any solution that works, as I've discovered roadblocks at the end of every path I've tried (hence you seeing me in multiple threads). And you all know better than I do on what the right solution is.

If it helps, my primary concerns with whatever solution is chosen are (1) editor support (I know a PR exists against the Standard VSCode plugin to support ts-standard although I'm a bit hesitant having to ask my colleagues to pull and build it), (2) Vue support for both JS and TS script types in Vue files (I don't think I've seen too many issues with this), and (3) mixed repo support--I've seen a few attempts at making TS and Standard (rules not library) work together that raise TS-specific lint errors on JS files.

[Raynos]

@JeffSpies Your usecase sounds very custom.

I had a custom use case for standard + typescript + .js files with jsdoc comments. I ended up creating https://github.com/Raynos/tsdocstandard

Creating a module that uses standard-engine and customizes rules to be favorible for JS / TS / Vue etc will get you good bang for buck.

[feross]

@JeffSpies Just wanted to say that we've merged the ts-standard VSCode support PR and released a new version now :)

As to the original suggestion of merging standardx into standard, I agree that maintaining all these variants is too time-consuming. Is it possible that standardx should never have been released? What's the advantage of a middle-ground between standard and just ejecting out to raw eslint with an .eslintrc that extends eslint-config-standard, etc.?

[Raynos]

@feross

The main advantages of standardx are

• Install one top level dependency. ( eslint requires many top level dependencies because of plugins and configs and so much bullshit )
• No extra files in my project, just a single standardx key in my package.json
• I can npm install standard@latest to get new rules, there's no way of getting new rules if I ejected to a 100 line .eslintrc; forget about it.

I just really want standard but i also want 'use strict' linting and no-console linting.

The alternative is to do ${company}-standard using standard-engine like I've done with http://ghub.io/tsdocstandard

But that has a high overhead of having to create & maintain 2 github repos & 2 npm packages instead of just installing a package and editing a few lines of JSON in my package.json.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

[voxpelli]

I think this is still an interesting approach