refactor remark custom blockquotes

[chenxsan]

1. I'm removing remark-custom-blockquotes from this repository as I think it's a bad idea to rely on exotic packages without any tests. Last time I upgraded it to 1.0.1, it just broken out of my expectation. Sure I can make pull requests to exotic packages, but normally it would take a long time to get it merged because people are doing it for free, it's not possible to ask them to respond immediately.
2. blockquote is bad to use for those tips/warnings/todos. They're not really blockquotes at all. Thus I changed blockquote to aside.
3. Use Tip, Warning and Todo for headings. It's explicit, users can tell it at first sight instead of guessing it from the background color.

Regarding the styles/colors/typography/etc., let me know if you have any other suggestion.

Before

After

Preview

https://webpack-js-org-git-fork-chenxsan-feature-customize-aside.webpack-docs.vercel.app/concepts/

[vercel]

This pull request is being automatically deployed with Vercel (learn more).
To see the status of your deployment, click below or on the icon next to each commit.

🔍 Inspect: https://vercel.com/webpack-docs/webpack-js-org/ad3ddnmm6
✅ Preview: https://webpack-js-org-git-fork-chenxsan-feature-customize-aside.webpack-docs.vercel.app

[snitin315]

Can we reduce the blank space?

[montogeek]

Please revert this change, this repository shouldn't have applications codes, this repository is only for documentation and its respective UI code.

If the external repo breaks the repo, please fork it or create a new one, but keep it as a dependency, outside of this repo.

[chenxsan]

@montogeek Sorry but I don't get the point why you would insist this repository shouldn't have applications codes as I'm not familiar with the history of this repository. Can you share what kind of benefits it will bring? So far as I learned in this repository, there's no benefit but defects as I listed in the beginning.

Take this #4123 (comment) for example, that webpack plugin I wrote would only work for this specific repository, I don't know why others would need it. Let's say I agree with you and publish it as a npm package, then one day someone forks it because I don't maintain it anymore, then someone forks the forked, etc., seriously, it would be a nightmare for reviewers to track or review.

BTW, do you have any idea who is in charge of the vercel account hosting the preview of this repository? I believe it's my third time asking you for help :) just in case you missed it because of too many notifications.

[montogeek]

That is how it was decided when this repo was created/extracted from the main webpack repository. It is only for documentation, anything else that you need should be external, it keeps it focused and easy to maintain, specially for non very technical contributors.

I don't know why others would need it

Nobody knows, but we know that is shouldn't be there, they can be a different repo an use them using git protocol instead of the npm registry.

What is your email? I need to add you.

[chenxsan]

That is how it was decided when this repo was created/extracted from the main webpack repository. It is only for documentation, anything else that you need should be external, it keeps it focused and easy to maintain, specially for non very technical contributors.

I don't know why others would need it

Nobody knows, but we know that is shouldn't be there, they can be a different repo an use them using git protocol instead of the npm registry.

What is your email? I need to add you.

deleted.

[chenxsan]

That is how it was decided when this repo was created/extracted from the main webpack repository. It is only for documentation, anything else that you need should be external, it keeps it focused and easy to maintain, specially for non very technical contributors.

I don't know why others would need it

Nobody knows, but we know that is shouldn't be there, they can be a different repo an use them using git protocol instead of the npm registry.

What is your email? I need to add you.

Make sure you add @sokra too, thanks.

[chenxsan]

That is how it was decided when this repo was created/extracted from the main webpack repository. It is only for documentation, anything else that you need should be external, it keeps it focused and easy to maintain, specially for non very technical contributors.

I believe we should discuss this again. It was decided from the beginning doesn't mean we should stick to it all the time.

We've welcomed some new contributors in the last month who have contributed to the non technical contents only

So far no one has any problem with those application codes.

What I think would be problems are something like slow CI which I have fixed.

[montogeek]

This repository is not a for an application and all its code, it is just for the documentation, so the actual application code should be minimal. I really like this approach, to keep the 2 things separate, one is the pure documentation, the other is the underlying application code that powers up the site, navigation, etc.

So far no one has any problem with those application codes.

Probably because it happens in the GitHub UI, which is fine for small changes.

[chenxsan]

This repository is not a for an application and all its code, it is just for the documentation, so the actual application code should be minimal. I really like this approach, to keep the 2 things separate, one is the pure documentation, the other is the underlying application code that powers up the site, navigation, etc.

Sure we should focus on documentation. But we need application code to support the documentation, to make the documentation user-friendly, accessible, beautiful, and fast. Take react.js for example, it has to maintain its own plugins https://github.com/reactjs/reactjs.org/tree/master/plugins as well. Otherwise we would ask users to read the raw markdown files, which I believe would frighten them.

So far no one has any problem with those application codes.

Probably because it happens in the GitHub UI, which is fine for small changes.

That could be true since most changes are small ones. If most non technical contributors can contribute in the Github UI, then why would we care to separate application code from this repository just because we're afraid to frighten them away? It just backs my view that we should make it easy for technical contributors as long as we won't block non technical contributors from contributing, and that's the main reason I want to bring those plugins, etc. into this repository.

Btw, with the prevailing of tools like create-react-app, vue-cli, people who would use webpack directly won't really be non technical contributors in my opinion. Them might contribute only to non technical contents, but they're potential technical contributors. I believe contributors like @snitin315 @jeffin143 @jamesgeorge007 @anshumanv all can contribute to the application code if them want :)

[montogeek]

Alright, So do you plan to move all plugins to the repo? What factors do you use to decide?

[chenxsan]

Alright, So do you plan to move all plugins to the repo? What factors do you use to decide?

I didn't mean all plugins, that would be insane doing that. Just some when they won't cover our use cases or meet our demands.

Take this remark custom blockquotes for example:

1. There're no tests
2. The use case here has changed a lot, e.g., from blockquote to aside
3. I believe I've made some pull requests to your repositories, and it took a while to get them merged. I don't like it because the time you review, I might already forget the context I once had, it's difficult to pick it up again. I'm not blaming anyone here for taking a long time to review, because it's how open source works, all of you are doing these great jobs for free.

After migrating to this repository:

1. we can tail the code for our specific use cases
2. we could iterate faster as long as someone's maintaining this repository. The more exotic packages we have, the more points of failure we have.

[chenxsan]

@montogeek If you're still hesitate about this change, here's what I think:

1. We can land the change first to see how things are going.
2. If we should get into any big trouble in future regarding your worry, we can consider rolling them back with external packages.

An alternative proposal is to maintain those external packages under webpack's control. In that case, maintainers who have write access to this repository won't have problems like long time waiting for pull request to be merged into external packages. But still, we're likely to have other problems like npm link not working etc., I can't remember how many times had I searched google for that keyword every year, which are obviously maintenance burden to contributors.

[montogeek]

Feel free to merge it :)

[chenxsan]

@montogeek Thank you! I appreciate it.