Skip to content

Conversation

@gupbeheer
Copy link
Contributor

@gupbeheer gupbeheer commented Nov 13, 2017

Technical committee: @TiFu @taxpon @sebastianhaas @kenisteward @Vrolijkx

PR checklist

  • Read the contribution guidelines.
  • Ran the shell script under ./bin/ to update Petstore sample so that CIs can verify the change. (For instance, only need to run ./bin/{LANG}-petstore.sh and ./bin/security/{LANG}-petstore.sh if updating the {LANG} (e.g. php, ruby, python, etc) code generator or {LANG} client's mustache templates). Windows batch files can be found in .\bin\windows\.
  • Filed the PR against the correct branch: 3.0.0 branch for changes related to OpenAPI spec 3.0. Default: master.
  • Copied the technical committee to review the pull request if your PR is targeting a particular programming langauge.

Description of the PR

When I added the generated Typescript Angular code to my project, my 'tslint' did not like the generated code. I updated the code to make my 'tslint' happy. This PR is to share my changes with the community.

@kenisteward
Copy link
Contributor

kenisteward commented Nov 13, 2017 via email

@kenisteward
Copy link
Contributor

kenisteward commented Nov 13, 2017 via email

@kenisteward
Copy link
Contributor

kenisteward commented Nov 13, 2017 via email

@wing328
Copy link
Contributor

wing328 commented Nov 13, 2017

So I think what @kenisteward suggested is to use customized templates to meet different linting requirement and use the -t option when generating the code.

@kenisteward
Copy link
Contributor

@wing328 that is definitely one way of going about it. I honestly forgot about that! haha. I was trying to give a solution without them having to learn the inner workings of mustache stuff.

@gupbeheer while your changes meet your (and mostly my) ts lint restrictions there are some of them that are preferential and definitely may not (e.g. forcing single quotes instead of double is based on preference not necessity)

You could definitely create your own templates that fit your coding style but to be honest linting mostly covers keeping code made by developers under check to make sure we write similar code (in my opinion). Since this is generated, you can just ignore linting rules on this folder as you (should) never be working directly on this code.

@sebastianhaas
Copy link
Contributor

I go with @kenisteward here, I would recommend not putting the auto-generated sources in your project but rather include it per npm and use it as a dependency.

@gupbeheer
Copy link
Contributor Author

No problem. I saw the code I committed in #6751 and the linting errors that came up in the files I committed were 90% my new code. So I made it more 'as the other code' and made the linting pass. I thought I should contribute this. That is the reason for this PR.
In our own codebase we exempt the generated code from linting and we generate service clients and push them to our NPM registry by using the Typescript specific properties: --additional-properties npmName="",npmVersion="",npmRepository=""

@kenisteward
Copy link
Contributor

@gupbeheer great to hear! If you could close this issue then that'd be great :)

@gupbeheer gupbeheer closed this Nov 14, 2017
@gupbeheer gupbeheer deleted the typescript_angular_linting_fixes branch November 14, 2017 08:53
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants