-
-
Notifications
You must be signed in to change notification settings - Fork 5.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Migrate to webpack
#1168
Comments
The general advise for people asking "rollup or webpack?" has been use to use rollup for distributable packages (browser and/or node) and webpack for applications. This advise was given early on mostly due to webpack v2's inability to output ES6 modules, but it largely holds true today as rollup is typically faster and produces smaller bundle sizes while webpack tends to be more flexible for app-specific use cases like code splitting. Given this advise and without any other information or preferences to consider, Rollup would typically be the first choice for a distributed bundle like docsify's. My preference would be to 1) lower the priority of this task in favor of user-facing issues and 2) commit only to exploring webpack as an option if/when time allows or the need presents itself. Once we have separate webpack and rollup builds available we can compare build time, bundle size, learning curve, features, concerns, etc. |
Actually I feel the same for most cases. Rollup is probably better for the docsify bundle. In some cases though, Webpack's ES-spec-compliant features come in handy when you can not do certain things with Rollup. As an example, one time I wanted to make "package protected" exports, so that if anyone outside of my package tried to import something it would thrown a runtime error. I'm not sure about now, but the last time I tried to achieve this with Rollup (with circular dependencies in the mix) I couldn't get the module hoisting to work as expected, but it worked with Webpack. I think in general starting with Rollup first for a lib and only moving to Webpack if needed is the way to go. 👍
👍
👍 With all that said, what about Webpack (Parcel) for docsify sites generated by the CLI? 🤔 Personally I really like the idea of keeping it simple with script tags (traditional or of type=module). |
Removed it from the 5.0 Todo. |
I don't think we need to switch to Rollup. We learnt about the caveat (it treats missing dependencies as warnings), so now we know. And now we also have a tests in place to catch missing dependencies once I get a second review so I can merge #1189. Also, we can add this config to Rollup to throw an error instead of a warning: rollup/rollup#1906 (comment) I think we should close this, as we don't have a need to convert to Webpack. Let's re-open this if/when someone needs to convert to Webpack for some reason. Let's focus on features/improvements. |
We are currently using
rollup
for bundling. Though we never faced a major issue with it, rollup is built for libraries which are node focuses not the browser. We will be usingrollup
for our CLI project but asdocsify
is browser library, I would prefer to migrate towebpack
like its always recommended to usewebpack
for browser code.The text was updated successfully, but these errors were encountered: