Bundle size reduction

Hello. First of all I would like to thank you for your work on the project. It makes a lot easier to communicate with backend. Recently we started to use swagger-js for our widget service and what bothers me is the overall bundle size. Our service is installed on other websites that already have their own code, so every Kb counts. As far as I can see the big size is mainly because of these lib dependencies:

1. js-yaml I understand that most probably this library is included to have universal code for browsers and node. But for those who use swagger-js only as a browser client that is 44Kb (according to webpack bundle analyser plugin) of unused gzipped code. That is greater than jQuery with its 30Kb.
2. lodash-compat This version of lodash is discontinued, and if I already have lodash or lodash-es, I end up with 2 versions of the same library.
3. q As for q there is already an issue where it is confirmed that there will be an opportunity to use own promise lib. That is great to hear.

It would be great if swagger-js started to use es6 modules. Then we could import different versions of swagger-js. Those who need the lib for universal code could import swagger with js-yaml, while others would take a version without it. Or maybe there could be another npm package swagger-js-es just like lodash does for those who want swagger-js with lodash-es and promises from babel-polyfill for size reduction.

[a-ignatov-parc]

There is a way to get rid of js-yaml with webpack and it’s alias feature.

All you need to do is to mock safeLoad method like this:

// mock/js-yaml.js
export function safeLoad(body) {
  return JSON.parse(body);
}

And add alias to webpack’s config:

{
  alias: {
    'js-yaml': path.resolve('./mock/js-yaml'),
  },
}

And there you go! Bundle size now weighs ~200kb less.

The only prerequisite to this workaround is to use only json spec or otherwise you may end up with parsing errors.

[webron]

@advzr - thanks for the note. We are very close to releasing a brand new version of this library which handles almost everything you mention here. Our main dependency that remains here is still js-yaml but we’re looking into alternatives now as we’re trying to minimize the bundle size. We have a few thoughts about it, so hopefully it’ll work out.