You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I noticed this in our project because after adding swagger-ui-react we have all languages of highlight.js cluttering our bundles. I see that in the code you are already defining the languages to use for highlight.js but that has no effect as long as there is no esm version in the package.
There is already a es bundle in the package, I noticed though that I think it is the wrong one, it should be the es-core bundle and not the full bundle with all dependencies bundled. After fixing that I noticed that nothing is actually pointing to the es bundle, so I fixed the esm entrypoint, but then noticed that the es-bundle is just a commonjs bundle not an esm bundle, so no matter what I try and fix here, tree shaking in our webpack won't work.
webpack 4 does not support esm as output type, so I thought I might try to not bundle the code for the react package at all (not sure why webpack is used anyway in this case for the react package, just transpilling the files and putting them in the package should be fine). But when just using babel it does not work because of the absolute imports in the source. I then tried using babel-plugin-module-resolver, but it does not understand the dist directories and always links to src/
So it would be nice to have proper esm in the package (with import/export) so that the bundle size is reduced when using the swagger-ui-react package in a project that uses webpack to bundle it.
Is your feature request related to a problem?
kind of, bundle size
Describe the solution you'd like
Well that is why I created the ticket because I'm not sure what to do. I personally would just remove the absolute imports and use relative ones because I like that better anyway, but I assume you like absolute imports better. With relative imports it would be easy to just run babel to output the transpilled files to the package. (as can be seen in my commit above.)
Other possibility might be to migrate from webpack to rollup for this case, as it supports es modules bundles.
I really tried a lot to make babel-plugin-module-resolver work, but I can't figure out if that is ever supposed to work.
I have no other ideas right now.
The text was updated successfully, but these errors were encountered:
I managed to get babel-plugin-module-resolver working correctly but then noticed that this lib also imports yaml and svg files, so it would require to setup webpack loaders in the project where swagger-ui-react is used, so I guess that is not an option.
As a solution without a bundler seems to be not possible, I attempted to fix this by using rollup instead of Webpack to bundle an ESM version of swagger-ui, which in turn could then be consumed by swagger-ui-react.
Resolving yaml, json, svg imports etc. works via rollup.
There are however some more issues. One is the usage of Webpacks require.context (here) which is used to retrieve all available plugins and needs to be resolved during bundle time. There is also a rollup plugin for this, but it rewrites it to default imports while the code expects a star import, which results in rollup bailing out. This probably needs to be fixed in rollup-plugin-require-context (PR), but I'm not entirely sure if that is a bug or a misuse of the API. I fixed this for now by copying the plugin and fixing the issue in place.
The final bundle however fails at runtime either with
./node_modules/swagger-ui-react/index.js
Attempted import error: 'presets' is not exported from './swagger-ui-es-bundle-core'.
using CRA (Even though presets is exported in the Code, but for some reason disappears in the final bundle)
or with
TypeError: Cannot add property async, object is not extensible
at http://localhost:8080/web_modules/swagger-ui-react.js:20742:28
Content & configuration
I noticed this in our project because after adding
swagger-ui-react
we have all languages of highlight.js cluttering our bundles. I see that in the code you are already defining the languages to use for highlight.js but that has no effect as long as there is no esm version in the package.There is already a
es bundle
in the package, I noticed though that I think it is the wrong one, it should be thees-core
bundle and not the full bundle with all dependencies bundled. After fixing that I noticed that nothing is actually pointing to the es bundle, so I fixed the esm entrypoint, but then noticed that the es-bundle is just a commonjs bundle not an esm bundle, so no matter what I try and fix here, tree shaking in our webpack won't work.webpack 4 does not support esm as output type, so I thought I might try to not bundle the code for the react package at all (not sure why webpack is used anyway in this case for the react package, just transpilling the files and putting them in the package should be fine). But when just using babel it does not work because of the absolute imports in the source. I then tried using
babel-plugin-module-resolver
, but it does not understand the dist directories and always links tosrc/
You can see here what I tried: https://github.com/danez/swagger-ui/commit/e61f0c6b9584ca8d11036b1a3449abdccebb3e0d
So it would be nice to have proper
esm
in the package (with import/export) so that the bundle size is reduced when using theswagger-ui-react
package in a project that uses webpack to bundle it.Is your feature request related to a problem?
kind of, bundle size
Describe the solution you'd like
Well that is why I created the ticket because I'm not sure what to do. I personally would just remove the absolute imports and use relative ones because I like that better anyway, but I assume you like absolute imports better. With relative imports it would be easy to just run babel to output the transpilled files to the package. (as can be seen in my commit above.)
Other possibility might be to migrate from webpack to rollup for this case, as it supports es modules bundles.
I really tried a lot to makebabel-plugin-module-resolver
work, but I can't figure out if that is ever supposed to work.I have no other ideas right now.
The text was updated successfully, but these errors were encountered: