Skip to content
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

Closed
trusktr opened this issue May 10, 2020 · 5 comments
Closed

Migrate to webpack #1168

trusktr opened this issue May 10, 2020 · 5 comments

Comments

@trusktr
Copy link
Member

trusktr commented May 10, 2020

Status PoC

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 using rollup for our CLI project but as docsify is browser library, I would prefer to migrate to webpack like its always recommended to use webpack for browser code.

@jhildenbiddle
Copy link
Member

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.

@trusktr
Copy link
Member Author

trusktr commented Jun 6, 2020

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

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. 👍

  1. lower the priority of this task in favor of user-facing issues

👍

if/when ... the need presents itself

👍

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).

@trusktr
Copy link
Member Author

trusktr commented Jun 6, 2020

Removed it from the 5.0 Todo.

@anikethsaha
Copy link
Member

anikethsaha commented Jun 6, 2020

Agreed, though I would favor webpack personally cause I always get lost with the rollup's dependencies resolving thing. eg #1058, #1057

(Pretty sure I did miss there something)

So, anyway, if someone takes this would be great, though not a priority or blocker. 👍

@trusktr
Copy link
Member Author

trusktr commented Jun 10, 2020

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.

@trusktr trusktr closed this as completed Jun 10, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants