Not removing all semicolons

[Paulo Cesar]

the following code snippet doesn't get it's semicolon removed:

    function has(obj, path, ownPropertiesOnly) {
        if (ownPropertiesOnly === void 0) { ownPropertiesOnly = exports.defaultOptions.ownPropertiesOnly; }
         /*...*/
        return;
    }

[Bret Comnes]

Thanks for the report. Just to make note for future review, the semicolon after the return is removed.

The work around right now is to not paren single line conditionals, or break out the conditional block into its own line(s). In these cases, the semicolon is removed.

I'm not sure if this was intentional or not, but allowing semicolons in a single line, paren'd conditional block would allow for 2 to 3 short statements on a single line after the conditional.

[Paulo Cesar]

that code is generated by Typescript, and they said they won't change it (taking their words, "It's an issue for the code formatter") microsoft/TypeScript#6099 (comment)

[Bret Comnes]

Hrmm. Can you clarify your goals here? If I understand correctly, it sounds like you are trying to bring compiled typescript output in line with Standard via standard-format?

[Paulo Cesar]

yes, I want the output from Typescript to be standardized, because I'm using Typescript for a library that I'm a collaborator, but the owner doesn't want to rely on Typescript, so I need to enforce the standard on PRs and patchs on plain .js

[Bret Comnes]

We are working on making the formatter more strict, so that there are less edge cases like this (eg it can make #27 standard compliant).

That being said, that goal of that is mainly to find unexpected edge cases, not really support people trying to make compiled/transpiled output standard compliant.

Its not my business what you do 😉 but it seems like your use case might be better served by a module interface (e.g. publish your built typescript as an npm module (typscript -> es5) and have the project that enforces standard against its code consume the typescript code as a module). Standard does not enforce linting against anything in node_modules.

Linting and formatting tools for type script should be done at that level, and not worry about the compiled output (beyond correctness).

[Paulo Cesar]

yeah, that's the problem, Microsoft said this is a matter for a formatter, and the formatter throws is back to them... guess I'll just use esformatter and change the rules json for now

[Bret Comnes]

If you see a quick fix that we can apply to https://github.com/maxogden/standard-format/blob/master/rc/esformatter.json I'm open to a PR as well. I didn't see any obvious fixes. It will hopefully be fixed after we do a code sprint on the formatter in early 2016.

[Feross Aboukhadijeh]

To be clear, @bcomnes is just saying that it's probably a bit futile to try to hope that code that's generated from thew TypeScript compiler will ever be pretty. You're better off doing what he suggested.

The formatter should produce standard code whenever it's possible to do so. I think this is a case where that's possible. We should be removing extra semicolons.

[Paulo Cesar]

yeah, I've also had a problem with their else always be in next line (in #135), and standard-format doesn't align them on same line, but I'll be doing it manually

[Feross Aboukhadijeh]

You should use standard --fix instead of this package. standard-format isn't being actively maintained anymore.