Open vlad-zhukov opened 6 years ago
Whoa, haven't thought the linters have such low usage - would be interesting to know how many people are using it from within the convenience package, but it will probably resemble the usage of the individual blocks.
Thanks for the stats in any case!
If we go on and move blocks to the org, I'd like to have them in individual repositories - so an external maintainer for the elm
block for example, doesn't need to be notified about / be able to push to other blocks.
In order to keep the structure, style etc aligned, what do you think about a "#0CJS" toolkit? I'd happy to help out building one, maybe with prettier & ava in the beginning, and then we can see what we need to add there.
Then each blocks scripts
section would be something like "fmt": "blocks-dev fmt"
, "test": "blocks-dev test"
and needs only one dev dependency to get started.
If we go on and move blocks to the org, I'd like to have them in individual repositories
That's the plan.
In order to keep the structure, style etc aligned, what do you think about a "#0CJS" toolkit?
It's a good idea to have something like this eventually but right now there aren't many configs and they will have certain changes soon.
they will have certain changes soon
Which is a good reason to have it in such a package 😜
For only moving elm
we could extract what we need and set it up within the repo and once we're moving more blocks we can see what is shared and put that in the toolkit.
This way we can start now without any overhead, but have a plan for the future 💪
@zcei would you like to work on moving it? Note that there is also an e2e test inside the webpack
package.
Sure, I could tackle it on Wednesday.
Wow, great job gathering all the stats! 🐰
I think we should settle on a decision whether to move those unpopular blocks into single repos for each block or move them into a new monorepo (webpack-blocks-contrib
?).
Personally, I'm biased towards Elm and would like to see it stay in the primary repo. However, I understand that it's rather niche and would not be upset if it were moved.
@farism If you would like to maintain it we could give you an access to the new repo we move it to! 😏
First stab done via git subtree split
- smooth experience:
https://github.com/webpack-blocks/elm
Still need to setup Travis.
@farism is that something you'd like to do? (like Elm block maintenance in general, I can setup Travis if you like)
git subtree split
TIL 😳
Is anyone interested in taking over that task? Will close it otherwise...
We bring this idea from time to time and we finally have to just do it, so I decided to add it to the 2.0 roadmap (#264). Now I went ahead and gathered some stats from npm:
webpack-blocks
@webpack-blocks/assets
@webpack-blocks/babel
@webpack-blocks/core
@webpack-blocks/dev-server
@webpack-blocks/elm
@webpack-blocks/eslint
@webpack-blocks/extract-text
@webpack-blocks/postcss
@webpack-blocks/sass
@webpack-blocks/tslint
@webpack-blocks/typescript
@webpack-blocks/uglify
@webpack-blocks/webpack
I am very surprised the vast majority of block are very popular and have so close download stats! There are, however, 3 exceptions:
elm
: this is the 1st candidate to be moved out of the monorepo. It's framework-specific, niche, takes a lot of time to download and build and very often breaks the CI.tslint
: despite the fact it was added more than a year ago it has a drastically low download number. Looks like the majority of developers prefer using linters outside of webpack from the command line.eslint
: it's a very new block but I believe it's not going to become popular enough. I expect it to have a similar amount of downloads as thetslint
block and that makes it another candidate to be moved.For now I am insistently suggesting to move the
elm
block into its own repo under thewebpack-blocks
org.