Fix NPM build for Typescript-fetch

[JFCote]

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, ./bin/openapi3/{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\. If contributing template-only or documentation-only changes which will change sample output, be sure to build the project first.
• Filed the PR against the correct branch: master, 4.1.x, 5.0.x. Default: master.
• Copied the technical committee to review the pull request if your PR is targeting a particular programming language.

@TiFu (2017/07) @taxpon (2017/07) @sebastianhaas (2017/07) @kenisteward (2017/07) @Vrolijkx (2017/09) @macjohnny (2018/01) @nicokoenig (2018/09) @topce (2018/10) @akehir (2019/07)

Description of the PR

This PR fixes 2 things:

1. The npm build was "working" but was not usable as a package because there was no output generated (Fix by adding the .npmignore file). Because of this, when you used the package via npm, webpack was always telling you that you need a specific loader for ts files. A real package should contains compiled code (.js).
2. I followed a tutorial on how to do a good typescript package so I followed convention of putting "source" code in the "src" folder instead of directly at the root.

I followed this tutorial to do a good npm package: https://medium.com/cameron-nokes/the-30-second-guide-to-publishing-a-typescript-package-to-npm-89d93ff7bccd

[TiFu]

LGTM if the circleci failure is unrelated

[macjohnny]

@JFCote can you please add the .npmignore files to the samples?

Untracked files:
(use "git add ..." to include in what will be committed)
samples/client/petstore/typescript-fetch/builds/es6-target/.npmignore
samples/client/petstore/typescript-fetch/builds/with-npm-version/.npmignore

[JFCote]

@macjohnny Currently in vacation, will check all of this when I'm back! Thanks for the review!

[Bessonov]

@JFCote

I followed a tutorial on how to do a good typescript package so I followed convention of putting "source" code in the "src" folder instead of directly at the root.

Although we use src folder by default, this is a breaking change for us.

[JFCote]

@Bessonov Can you explain a little bit more how this is a breaking change? If you use npm publish, you should'nt have any problem importing the resulting package, even if the structure has changed because webpack take care of everything.

Let us know what is your use case. Thanks

[Bessonov]

We don't use it as a whole module, but integrate it in own api module with some utilities and configuration. Basically, we have following structure:

- myApi
- src
- index.ts <-- exports only relevant and configured parts
- configuration.ts
- fetch <-- here we place the generated artifacts

After this change the artifacts are not under src/fetch, but src/fetch/src. Of course we can handle it with some post processing, but well, that's a definition of breaking changes :)

[JFCote]

@Bessonov I understand now. The changes was supposed to be mostly for the npm version of the generator but it seems it has created some regression for use case like yours.

@macjohnny What do you suggest we do for this?

[Bessonov]

@JFCote no problem. I've implemented a postprocessing hook now, so don't care about us 👍

[rob-deutsch]

@Bessonov what postprocessing did you implement for this?

Like you, I was also using openapi-generator to integrate it into an existing npm package.

[Bessonov]

@rob-deutsch because all generators has some flaws, we use a run scripts like (pseudo code):

#!/bin/bash# pre processing
rm -rf ...
# do work
docker run generator ....
# post processing# remove filesforpathin".gitignore"".openapi-generator-ignore""tsconfig.json"".openapi-generator";do
rm -rf "${rest_api}/src/fetch/${path}"done# new version of generator create resources in src folder
mv ${rest_api}/src/fetch/src/*${rest_api}/src/fetch
rmdir ${rest_api}/src/fetch/src

So, no magic.

[rob-deutsch]

Thanks @Bessonov. That's more elegant than my import * from './service/src'; solution

[rob-deutsch]

[edit]: Disregard this post. I was running into issues with the additional tsconfig.json file.

[JFCote]

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, ./bin/openapi3/{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\. If contributing template-only or documentation-only changes which will change sample output, be sure to build the project first.
• Filed the PR against the correct branch: master, 4.1.x, 5.0.x. Default: master.
• Copied the technical committee to review the pull request if your PR is targeting a particular programming language.

@TiFu (2017/07) @taxpon (2017/07) @sebastianhaas (2017/07) @kenisteward (2017/07) @Vrolijkx (2017/09) @macjohnny (2018/01) @nicokoenig (2018/09) @topce (2018/10) @akehir (2019/07)

Description of the PR

This PR fixes 2 things:

1. The npm build was "working" but was not usable as a package because there was no output generated (Fix by adding the .npmignore file). Because of this, when you used the package via npm, webpack was always telling you that you need a specific loader for ts files. A real package should contains compiled code (.js).
2. I followed a tutorial on how to do a good typescript package so I followed convention of putting "source" code in the "src" folder instead of directly at the root.

I followed this tutorial to do a good npm package: https://medium.com/cameron-nokes/the-30-second-guide-to-publishing-a-typescript-package-to-npm-89d93ff7bccd

[TiFu]

LGTM if the circleci failure is unrelated

[macjohnny]

@JFCote can you please add the .npmignore files to the samples?

Untracked files:
(use "git add ..." to include in what will be committed)
samples/client/petstore/typescript-fetch/builds/es6-target/.npmignore
samples/client/petstore/typescript-fetch/builds/with-npm-version/.npmignore

[JFCote]

@macjohnny Currently in vacation, will check all of this when I'm back! Thanks for the review!

[Bessonov]

@JFCote

I followed a tutorial on how to do a good typescript package so I followed convention of putting "source" code in the "src" folder instead of directly at the root.

Although we use src folder by default, this is a breaking change for us.

[JFCote]

@Bessonov Can you explain a little bit more how this is a breaking change? If you use npm publish, you should'nt have any problem importing the resulting package, even if the structure has changed because webpack take care of everything.

Let us know what is your use case. Thanks

[Bessonov]

We don't use it as a whole module, but integrate it in own api module with some utilities and configuration. Basically, we have following structure:

- myApi
- src
- index.ts <-- exports only relevant and configured parts
- configuration.ts
- fetch <-- here we place the generated artifacts

After this change the artifacts are not under src/fetch, but src/fetch/src. Of course we can handle it with some post processing, but well, that's a definition of breaking changes :)

[JFCote]

@Bessonov I understand now. The changes was supposed to be mostly for the npm version of the generator but it seems it has created some regression for use case like yours.

@macjohnny What do you suggest we do for this?

[Bessonov]

@JFCote no problem. I've implemented a postprocessing hook now, so don't care about us 👍

[rob-deutsch]

@Bessonov what postprocessing did you implement for this?

Like you, I was also using openapi-generator to integrate it into an existing npm package.

[Bessonov]

@rob-deutsch because all generators has some flaws, we use a run scripts like (pseudo code):

#!/bin/bash# pre processing
rm -rf ...
# do work
docker run generator ....
# post processing# remove filesforpathin".gitignore"".openapi-generator-ignore""tsconfig.json"".openapi-generator";do
rm -rf "${rest_api}/src/fetch/${path}"done# new version of generator create resources in src folder
mv ${rest_api}/src/fetch/src/*${rest_api}/src/fetch
rmdir ${rest_api}/src/fetch/src

So, no magic.

[rob-deutsch]

Thanks @Bessonov. That's more elegant than my import * from './service/src'; solution

[rob-deutsch]

[edit]: Disregard this post. I was running into issues with the additional tsconfig.json file.

[JFCote]

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, ./bin/openapi3/{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\. If contributing template-only or documentation-only changes which will change sample output, be sure to build the project first.
• Filed the PR against the correct branch: master, 4.1.x, 5.0.x. Default: master.
• Copied the technical committee to review the pull request if your PR is targeting a particular programming language.

@TiFu (2017/07) @taxpon (2017/07) @sebastianhaas (2017/07) @kenisteward (2017/07) @Vrolijkx (2017/09) @macjohnny (2018/01) @nicokoenig (2018/09) @topce (2018/10) @akehir (2019/07)

Description of the PR

This PR fixes 2 things:

1. The npm build was "working" but was not usable as a package because there was no output generated (Fix by adding the .npmignore file). Because of this, when you used the package via npm, webpack was always telling you that you need a specific loader for ts files. A real package should contains compiled code (.js).
2. I followed a tutorial on how to do a good typescript package so I followed convention of putting "source" code in the "src" folder instead of directly at the root.

I followed this tutorial to do a good npm package: https://medium.com/cameron-nokes/the-30-second-guide-to-publishing-a-typescript-package-to-npm-89d93ff7bccd

[TiFu]

LGTM if the circleci failure is unrelated

[macjohnny]

@JFCote can you please add the .npmignore files to the samples?

Untracked files:
(use "git add ..." to include in what will be committed)
samples/client/petstore/typescript-fetch/builds/es6-target/.npmignore
samples/client/petstore/typescript-fetch/builds/with-npm-version/.npmignore

[JFCote]

@macjohnny Currently in vacation, will check all of this when I'm back! Thanks for the review!

[Bessonov]

@JFCote

I followed a tutorial on how to do a good typescript package so I followed convention of putting "source" code in the "src" folder instead of directly at the root.

Although we use src folder by default, this is a breaking change for us.

[JFCote]

@Bessonov Can you explain a little bit more how this is a breaking change? If you use npm publish, you should'nt have any problem importing the resulting package, even if the structure has changed because webpack take care of everything.

Let us know what is your use case. Thanks

[Bessonov]

We don't use it as a whole module, but integrate it in own api module with some utilities and configuration. Basically, we have following structure:

- myApi
- src
- index.ts <-- exports only relevant and configured parts
- configuration.ts
- fetch <-- here we place the generated artifacts

After this change the artifacts are not under src/fetch, but src/fetch/src. Of course we can handle it with some post processing, but well, that's a definition of breaking changes :)

[JFCote]

@Bessonov I understand now. The changes was supposed to be mostly for the npm version of the generator but it seems it has created some regression for use case like yours.

@macjohnny What do you suggest we do for this?

[Bessonov]

@JFCote no problem. I've implemented a postprocessing hook now, so don't care about us 👍

[rob-deutsch]

@Bessonov what postprocessing did you implement for this?

Like you, I was also using openapi-generator to integrate it into an existing npm package.

[Bessonov]

@rob-deutsch because all generators has some flaws, we use a run scripts like (pseudo code):

#!/bin/bash# pre processing
rm -rf ...
# do work
docker run generator ....
# post processing# remove filesforpathin".gitignore"".openapi-generator-ignore""tsconfig.json"".openapi-generator";do
rm -rf "${rest_api}/src/fetch/${path}"done# new version of generator create resources in src folder
mv ${rest_api}/src/fetch/src/*${rest_api}/src/fetch
rmdir ${rest_api}/src/fetch/src

So, no magic.

[rob-deutsch]

Thanks @Bessonov. That's more elegant than my import * from './service/src'; solution

[rob-deutsch]

[edit]: Disregard this post. I was running into issues with the additional tsconfig.json file.

[JFCote]

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, ./bin/openapi3/{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\. If contributing template-only or documentation-only changes which will change sample output, be sure to build the project first.
• Filed the PR against the correct branch: master, 4.1.x, 5.0.x. Default: master.
• Copied the technical committee to review the pull request if your PR is targeting a particular programming language.

@TiFu (2017/07) @taxpon (2017/07) @sebastianhaas (2017/07) @kenisteward (2017/07) @Vrolijkx (2017/09) @macjohnny (2018/01) @nicokoenig (2018/09) @topce (2018/10) @akehir (2019/07)

Description of the PR

This PR fixes 2 things:

1. The npm build was "working" but was not usable as a package because there was no output generated (Fix by adding the .npmignore file). Because of this, when you used the package via npm, webpack was always telling you that you need a specific loader for ts files. A real package should contains compiled code (.js).
2. I followed a tutorial on how to do a good typescript package so I followed convention of putting "source" code in the "src" folder instead of directly at the root.

I followed this tutorial to do a good npm package: https://medium.com/cameron-nokes/the-30-second-guide-to-publishing-a-typescript-package-to-npm-89d93ff7bccd

[TiFu]

LGTM if the circleci failure is unrelated

[macjohnny]

@JFCote can you please add the .npmignore files to the samples?

Untracked files:
(use "git add ..." to include in what will be committed)
samples/client/petstore/typescript-fetch/builds/es6-target/.npmignore
samples/client/petstore/typescript-fetch/builds/with-npm-version/.npmignore

[JFCote]

@macjohnny Currently in vacation, will check all of this when I'm back! Thanks for the review!

[Bessonov]

@JFCote

I followed a tutorial on how to do a good typescript package so I followed convention of putting "source" code in the "src" folder instead of directly at the root.

Although we use src folder by default, this is a breaking change for us.

[JFCote]

@Bessonov Can you explain a little bit more how this is a breaking change? If you use npm publish, you should'nt have any problem importing the resulting package, even if the structure has changed because webpack take care of everything.

Let us know what is your use case. Thanks

[Bessonov]

We don't use it as a whole module, but integrate it in own api module with some utilities and configuration. Basically, we have following structure:

- myApi
- src
- index.ts <-- exports only relevant and configured parts
- configuration.ts
- fetch <-- here we place the generated artifacts

After this change the artifacts are not under src/fetch, but src/fetch/src. Of course we can handle it with some post processing, but well, that's a definition of breaking changes :)

[JFCote]

@Bessonov I understand now. The changes was supposed to be mostly for the npm version of the generator but it seems it has created some regression for use case like yours.

@macjohnny What do you suggest we do for this?

[Bessonov]

@JFCote no problem. I've implemented a postprocessing hook now, so don't care about us 👍

[rob-deutsch]

@Bessonov what postprocessing did you implement for this?

Like you, I was also using openapi-generator to integrate it into an existing npm package.

[Bessonov]

@rob-deutsch because all generators has some flaws, we use a run scripts like (pseudo code):

#!/bin/bash# pre processing
rm -rf ...
# do work
docker run generator ....
# post processing# remove filesforpathin".gitignore"".openapi-generator-ignore""tsconfig.json"".openapi-generator";do
rm -rf "${rest_api}/src/fetch/${path}"done# new version of generator create resources in src folder
mv ${rest_api}/src/fetch/src/*${rest_api}/src/fetch
rmdir ${rest_api}/src/fetch/src

So, no magic.

[rob-deutsch]

Thanks @Bessonov. That's more elegant than my import * from './service/src'; solution

[rob-deutsch]

[edit]: Disregard this post. I was running into issues with the additional tsconfig.json file.

[JFCote]

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, ./bin/openapi3/{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\. If contributing template-only or documentation-only changes which will change sample output, be sure to build the project first.
• Filed the PR against the correct branch: master, 4.1.x, 5.0.x. Default: master.
• Copied the technical committee to review the pull request if your PR is targeting a particular programming language.

@TiFu (2017/07) @taxpon (2017/07) @sebastianhaas (2017/07) @kenisteward (2017/07) @Vrolijkx (2017/09) @macjohnny (2018/01) @nicokoenig (2018/09) @topce (2018/10) @akehir (2019/07)

Description of the PR

This PR fixes 2 things:

1. The npm build was "working" but was not usable as a package because there was no output generated (Fix by adding the .npmignore file). Because of this, when you used the package via npm, webpack was always telling you that you need a specific loader for ts files. A real package should contains compiled code (.js).
2. I followed a tutorial on how to do a good typescript package so I followed convention of putting "source" code in the "src" folder instead of directly at the root.

I followed this tutorial to do a good npm package: https://medium.com/cameron-nokes/the-30-second-guide-to-publishing-a-typescript-package-to-npm-89d93ff7bccd

[TiFu]

LGTM if the circleci failure is unrelated

[macjohnny]

@JFCote can you please add the .npmignore files to the samples?

Untracked files:
(use "git add ..." to include in what will be committed)
samples/client/petstore/typescript-fetch/builds/es6-target/.npmignore
samples/client/petstore/typescript-fetch/builds/with-npm-version/.npmignore

[JFCote]

@macjohnny Currently in vacation, will check all of this when I'm back! Thanks for the review!

[Bessonov]

@JFCote

I followed a tutorial on how to do a good typescript package so I followed convention of putting "source" code in the "src" folder instead of directly at the root.

Although we use src folder by default, this is a breaking change for us.

[JFCote]

@Bessonov Can you explain a little bit more how this is a breaking change? If you use npm publish, you should'nt have any problem importing the resulting package, even if the structure has changed because webpack take care of everything.

Let us know what is your use case. Thanks

[Bessonov]

We don't use it as a whole module, but integrate it in own api module with some utilities and configuration. Basically, we have following structure:

- myApi
- src
- index.ts <-- exports only relevant and configured parts
- configuration.ts
- fetch <-- here we place the generated artifacts

After this change the artifacts are not under src/fetch, but src/fetch/src. Of course we can handle it with some post processing, but well, that's a definition of breaking changes :)

[JFCote]

@Bessonov I understand now. The changes was supposed to be mostly for the npm version of the generator but it seems it has created some regression for use case like yours.

@macjohnny What do you suggest we do for this?

[Bessonov]

@JFCote no problem. I've implemented a postprocessing hook now, so don't care about us 👍

[rob-deutsch]

@Bessonov what postprocessing did you implement for this?

Like you, I was also using openapi-generator to integrate it into an existing npm package.

[Bessonov]

@rob-deutsch because all generators has some flaws, we use a run scripts like (pseudo code):

#!/bin/bash# pre processing
rm -rf ...
# do work
docker run generator ....
# post processing# remove filesforpathin".gitignore"".openapi-generator-ignore""tsconfig.json"".openapi-generator";do
rm -rf "${rest_api}/src/fetch/${path}"done# new version of generator create resources in src folder
mv ${rest_api}/src/fetch/src/*${rest_api}/src/fetch
rmdir ${rest_api}/src/fetch/src

So, no magic.

[rob-deutsch]

Thanks @Bessonov. That's more elegant than my import * from './service/src'; solution

[rob-deutsch]

[edit]: Disregard this post. I was running into issues with the additional tsconfig.json file.

[JFCote]

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, ./bin/openapi3/{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\. If contributing template-only or documentation-only changes which will change sample output, be sure to build the project first.
• Filed the PR against the correct branch: master, 4.1.x, 5.0.x. Default: master.
• Copied the technical committee to review the pull request if your PR is targeting a particular programming language.

@TiFu (2017/07) @taxpon (2017/07) @sebastianhaas (2017/07) @kenisteward (2017/07) @Vrolijkx (2017/09) @macjohnny (2018/01) @nicokoenig (2018/09) @topce (2018/10) @akehir (2019/07)

Description of the PR

This PR fixes 2 things:

1. The npm build was "working" but was not usable as a package because there was no output generated (Fix by adding the .npmignore file). Because of this, when you used the package via npm, webpack was always telling you that you need a specific loader for ts files. A real package should contains compiled code (.js).
2. I followed a tutorial on how to do a good typescript package so I followed convention of putting "source" code in the "src" folder instead of directly at the root.

I followed this tutorial to do a good npm package: https://medium.com/cameron-nokes/the-30-second-guide-to-publishing-a-typescript-package-to-npm-89d93ff7bccd

[TiFu]

LGTM if the circleci failure is unrelated

[macjohnny]

@JFCote can you please add the .npmignore files to the samples?

Untracked files:
(use "git add ..." to include in what will be committed)
samples/client/petstore/typescript-fetch/builds/es6-target/.npmignore
samples/client/petstore/typescript-fetch/builds/with-npm-version/.npmignore

[JFCote]

@macjohnny Currently in vacation, will check all of this when I'm back! Thanks for the review!

[Bessonov]

@JFCote

I followed a tutorial on how to do a good typescript package so I followed convention of putting "source" code in the "src" folder instead of directly at the root.

Although we use src folder by default, this is a breaking change for us.

[JFCote]

@Bessonov Can you explain a little bit more how this is a breaking change? If you use npm publish, you should'nt have any problem importing the resulting package, even if the structure has changed because webpack take care of everything.

Let us know what is your use case. Thanks

[Bessonov]

We don't use it as a whole module, but integrate it in own api module with some utilities and configuration. Basically, we have following structure:

- myApi
- src
- index.ts <-- exports only relevant and configured parts
- configuration.ts
- fetch <-- here we place the generated artifacts

After this change the artifacts are not under src/fetch, but src/fetch/src. Of course we can handle it with some post processing, but well, that's a definition of breaking changes :)

[JFCote]

@Bessonov I understand now. The changes was supposed to be mostly for the npm version of the generator but it seems it has created some regression for use case like yours.

@macjohnny What do you suggest we do for this?

[Bessonov]

@JFCote no problem. I've implemented a postprocessing hook now, so don't care about us 👍

[rob-deutsch]

@Bessonov what postprocessing did you implement for this?

Like you, I was also using openapi-generator to integrate it into an existing npm package.

[Bessonov]

@rob-deutsch because all generators has some flaws, we use a run scripts like (pseudo code):

#!/bin/bash# pre processing
rm -rf ...
# do work
docker run generator ....
# post processing# remove filesforpathin".gitignore"".openapi-generator-ignore""tsconfig.json"".openapi-generator";do
rm -rf "${rest_api}/src/fetch/${path}"done# new version of generator create resources in src folder
mv ${rest_api}/src/fetch/src/*${rest_api}/src/fetch
rmdir ${rest_api}/src/fetch/src

So, no magic.

[rob-deutsch]

Thanks @Bessonov. That's more elegant than my import * from './service/src'; solution

[rob-deutsch]

[edit]: Disregard this post. I was running into issues with the additional tsconfig.json file.

[JFCote]

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, ./bin/openapi3/{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\. If contributing template-only or documentation-only changes which will change sample output, be sure to build the project first.
• Filed the PR against the correct branch: master, 4.1.x, 5.0.x. Default: master.
• Copied the technical committee to review the pull request if your PR is targeting a particular programming language.

@TiFu (2017/07) @taxpon (2017/07) @sebastianhaas (2017/07) @kenisteward (2017/07) @Vrolijkx (2017/09) @macjohnny (2018/01) @nicokoenig (2018/09) @topce (2018/10) @akehir (2019/07)

Description of the PR

This PR fixes 2 things:

1. The npm build was "working" but was not usable as a package because there was no output generated (Fix by adding the .npmignore file). Because of this, when you used the package via npm, webpack was always telling you that you need a specific loader for ts files. A real package should contains compiled code (.js).
2. I followed a tutorial on how to do a good typescript package so I followed convention of putting "source" code in the "src" folder instead of directly at the root.

I followed this tutorial to do a good npm package: https://medium.com/cameron-nokes/the-30-second-guide-to-publishing-a-typescript-package-to-npm-89d93ff7bccd

[TiFu]

LGTM if the circleci failure is unrelated

[macjohnny]

@JFCote can you please add the .npmignore files to the samples?

Untracked files:
(use "git add ..." to include in what will be committed)
samples/client/petstore/typescript-fetch/builds/es6-target/.npmignore
samples/client/petstore/typescript-fetch/builds/with-npm-version/.npmignore

[JFCote]

@macjohnny Currently in vacation, will check all of this when I'm back! Thanks for the review!

[Bessonov]

@JFCote

I followed a tutorial on how to do a good typescript package so I followed convention of putting "source" code in the "src" folder instead of directly at the root.

Although we use src folder by default, this is a breaking change for us.

[JFCote]

@Bessonov Can you explain a little bit more how this is a breaking change? If you use npm publish, you should'nt have any problem importing the resulting package, even if the structure has changed because webpack take care of everything.

Let us know what is your use case. Thanks

[Bessonov]

We don't use it as a whole module, but integrate it in own api module with some utilities and configuration. Basically, we have following structure:

- myApi
- src
- index.ts <-- exports only relevant and configured parts
- configuration.ts
- fetch <-- here we place the generated artifacts

After this change the artifacts are not under src/fetch, but src/fetch/src. Of course we can handle it with some post processing, but well, that's a definition of breaking changes :)

[JFCote]

@Bessonov I understand now. The changes was supposed to be mostly for the npm version of the generator but it seems it has created some regression for use case like yours.

@macjohnny What do you suggest we do for this?

[Bessonov]

@JFCote no problem. I've implemented a postprocessing hook now, so don't care about us 👍

[rob-deutsch]

@Bessonov what postprocessing did you implement for this?

Like you, I was also using openapi-generator to integrate it into an existing npm package.

[Bessonov]

@rob-deutsch because all generators has some flaws, we use a run scripts like (pseudo code):

#!/bin/bash# pre processing
rm -rf ...
# do work
docker run generator ....
# post processing# remove filesforpathin".gitignore"".openapi-generator-ignore""tsconfig.json"".openapi-generator";do
rm -rf "${rest_api}/src/fetch/${path}"done# new version of generator create resources in src folder
mv ${rest_api}/src/fetch/src/*${rest_api}/src/fetch
rmdir ${rest_api}/src/fetch/src

So, no magic.

[rob-deutsch]

Thanks @Bessonov. That's more elegant than my import * from './service/src'; solution

[rob-deutsch]

[edit]: Disregard this post. I was running into issues with the additional tsconfig.json file.

[JFCote]

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, ./bin/openapi3/{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\. If contributing template-only or documentation-only changes which will change sample output, be sure to build the project first.
• Filed the PR against the correct branch: master, 4.1.x, 5.0.x. Default: master.
• Copied the technical committee to review the pull request if your PR is targeting a particular programming language.

@TiFu (2017/07) @taxpon (2017/07) @sebastianhaas (2017/07) @kenisteward (2017/07) @Vrolijkx (2017/09) @macjohnny (2018/01) @nicokoenig (2018/09) @topce (2018/10) @akehir (2019/07)

Description of the PR

This PR fixes 2 things:

1. The npm build was "working" but was not usable as a package because there was no output generated (Fix by adding the .npmignore file). Because of this, when you used the package via npm, webpack was always telling you that you need a specific loader for ts files. A real package should contains compiled code (.js).
2. I followed a tutorial on how to do a good typescript package so I followed convention of putting "source" code in the "src" folder instead of directly at the root.

I followed this tutorial to do a good npm package: https://medium.com/cameron-nokes/the-30-second-guide-to-publishing-a-typescript-package-to-npm-89d93ff7bccd

[TiFu]

LGTM if the circleci failure is unrelated

[macjohnny]

@JFCote can you please add the .npmignore files to the samples?

Untracked files:
(use "git add ..." to include in what will be committed)
samples/client/petstore/typescript-fetch/builds/es6-target/.npmignore
samples/client/petstore/typescript-fetch/builds/with-npm-version/.npmignore

[JFCote]

@macjohnny Currently in vacation, will check all of this when I'm back! Thanks for the review!

[Bessonov]

@JFCote

I followed a tutorial on how to do a good typescript package so I followed convention of putting "source" code in the "src" folder instead of directly at the root.

Although we use src folder by default, this is a breaking change for us.

[JFCote]

@Bessonov Can you explain a little bit more how this is a breaking change? If you use npm publish, you should'nt have any problem importing the resulting package, even if the structure has changed because webpack take care of everything.

Let us know what is your use case. Thanks

[Bessonov]

We don't use it as a whole module, but integrate it in own api module with some utilities and configuration. Basically, we have following structure:

- myApi
- src
- index.ts <-- exports only relevant and configured parts
- configuration.ts
- fetch <-- here we place the generated artifacts

After this change the artifacts are not under src/fetch, but src/fetch/src. Of course we can handle it with some post processing, but well, that's a definition of breaking changes :)

[JFCote]

@Bessonov I understand now. The changes was supposed to be mostly for the npm version of the generator but it seems it has created some regression for use case like yours.

@macjohnny What do you suggest we do for this?

[Bessonov]

@JFCote no problem. I've implemented a postprocessing hook now, so don't care about us 👍

[rob-deutsch]

@Bessonov what postprocessing did you implement for this?

Like you, I was also using openapi-generator to integrate it into an existing npm package.

[Bessonov]

@rob-deutsch because all generators has some flaws, we use a run scripts like (pseudo code):

#!/bin/bash# pre processing
rm -rf ...
# do work
docker run generator ....
# post processing# remove filesforpathin".gitignore"".openapi-generator-ignore""tsconfig.json"".openapi-generator";do
rm -rf "${rest_api}/src/fetch/${path}"done# new version of generator create resources in src folder
mv ${rest_api}/src/fetch/src/*${rest_api}/src/fetch
rmdir ${rest_api}/src/fetch/src

So, no magic.

[rob-deutsch]

Thanks @Bessonov. That's more elegant than my import * from './service/src'; solution

[rob-deutsch]

[edit]: Disregard this post. I was running into issues with the additional tsconfig.json file.