Bundle for swagger-client

[shockey]

Currently, our other JavaScript projects include browser bundles for folks not using a module bundler (old school!). swagger-client doesn't have one, though - there's a Webpack config for it but it's not available downstream.

Adding it to the npm module would allow folks to take advantage of tools like unpkg's module cdn and use swagger-client directly in the browser.

TODO

• Add a browser entry to package.json
• Add the bundle build to part of the main project build
• Host the files in the repository and update them during each release

[n-h]

@shockey + 1 Would love to see this. Is there a workaround for now?

[shockey]

There is - you can build your own bundle. Here's how:

• have node.js and npm installed on your system
• clone the swagger-js repository and open it in your terminal
• run npm install
• run npm run build-bundle

If all goes well, you should find a bundle file in browser/swagger-client.js.

[n-h]

OMG, awesome! It worked. Thanks for such a fast reply! 😄

[fsticza]

not so comfy though...

[Azuaron]

For the love of God, put that workaround in the README!

[PaulSearcy]

Expanding on @Azuaron comment above.
Readme also causes confusion in that browser example will not work after installing via npm.

Download via npm

 npm install swagger-client

Import in code

import Swagger from 'swagger-client'
// Or commonjs
const Swagger = require('swagger-client')

Import in browser

<script src='browser/swagger-client.js' type='text/javascript'></script>
<script>
    var swaggerClient = new SwaggerClient(specUrl);
</script>

I struggled with this for a second because later on:

In Browser

Prepare swagger-client.js by npm run build-bundle

which meant to me:

cd node_modules/swagger-client && npm run build-bundle

That promptly failed because installing from npm strangely enough only downloaded the dist folder and not the src folder .

So had to back out of project folder and use workaround stated above.

[shockey]

@PaulSearcy, the build instructions only work when you have a full copy of the project (e.g., by Git cloning) - you're not meant to be able to build when you've installed the module via npm 😄

[PaulSearcy]

@shockey yep, pointing out that the readme makes that assumption.

Just from my experience, I've seen JS libraries: do a 1 to 1 with github and npm, provide CDN links, release a bundled browser version usually in UMD ( like one of your to do items listed above), and/or explicitly state to git clone.

A minimal material design css library I use called MUI has a great example.

I usually first jump into node_modules for the library before I do a git clone so I don't have to switch my focus too much from my editor/terminal/window and usually I can extrapolate what I need from there. I also then don't need to do more clean up tasks down the line when I wonder why I have so many directories in my workspace. 😆

[stevage]

FYI, I think the TODO here is

• Add umd/ to .gitignore
• Add a "prepublishOnly" script to package.json that does essentially the same as bundle-build but puts the result in umd/index.js
• Advertise the fact that you can access the distributable at unpkg.com/swagger-client

As far as I know, that's all that's required. Since there is no files element in package.json, the generated file will be automatically included, and therefore picked up by unpkg.

[rezpe]

Hi @stevage , So i just need to fork and apply the changes you state in the todo and then pull request ?

[stevage]

@rezpe yes, as far as I know.

[rezpe]

@stevage Done. However, the pull request do not work according to the Jenkins CI job. Strange, since I did not change anything else ...

[cmidt-veasna]

It seem readme doc it's not up to date, the command to build for browser is changing from npm run build-bundle to npm run build:bundle according to package.json file.

[shockey]

As of the next release, a browser folder will be available in swagger-client with an index.js bundle file.

I didn't add a value for the browser field, since it seemed that the field was intended for browser-specific code, instead of bundled code. I think doing that would've aged especially badly with the coming age of <script type="module"> in browsers.

I also passed on hosting the files in the repo - we're likely to phase that out in the other projects in v4.0, so I didn't want to start it here. If there's demand for it, we can set up a GitHub Release asset pipeline that provides the file.

Thanks everyone!