Support for ESLint

[dmitmel]

Almost like the tslint block, but for JavaScript.

[zcei]

Copy 🍝 - needs to be ESLint as well 🙂

[dmitmel]

Oh, thanks :) These packages are very similar, so I've decided to copy files from the tslint block.

[zcei]

Sure, that's how I would have done as well 😉

[andywer]

Proposal: Let's extract the tslint block out of the core webpack-blocks repo into its own and let's put the eslint block into a separate repo as well.

We can still link to them in the README here, but trimming down the number of packages here might be a good idea. Thoughts?

@jvanbruegge

[dmitmel]

Well, I think these packages must be included in the webpack-blocks package because they are used in lots of projects (see their stats). But, your CI can't run all tests because there are too many packages. An ideal solution would be creating an organization and putting all packages into separate repositories.

[jvanbruegge]

@andywer
Would be ok with that, just dont forget to make a major version bump on the webpack-blocks package. I dont want all the setups suddenly breaking

[zcei]

I would really like to see most blocks in their own repo - that's why I initially blocked the webpack-blocks org org.
Though I think especially ESLint (& TSLint ?) should be treated first-class as they're nearly always used.

[andywer]

Then maybe let's postpone this decision (extra repo or not) for now 😉

@jvanbruegge That shouldn't be a breaking change. Should have no influence on user's where the sources reside.

@dmitmel Yeah, but the block's are more utility than core functionality and the download count of the tslint block is quite low.

The CI issue is quite annoying, though... We could try lerna run --parallel or lerna run --stream to circumvent that issue or try a different monorepo tool.

[dmitmel]

@andywer Would you like to add the eslint block or remove the tslint block?

[andywer]

@dmitmel Let's add the eslint block for now and decide on the overall strategy afterwards. That discussion shouldn't be a reason to block new features :)

[andywer]

In this case we can enter the version number already, since we will publish right away.

[vlad-zhukov]

I'd move unpopular and framework-specific blocks out of the main repo (for example elm). It will make installs and tests faster (good for both development and CI), but most importantly you can grant write access to repos to people who care about the block, and don't stop their development interests.

[vlad-zhukov]

@dmitmel Thanks for the PR! Would be great to have a few test cases similar to ones other blocks have.

[dmitmel]

@vlad-zhukov I've written some integration tests. Thanks for pointing out!

[vlad-zhukov]

LGTM.

Nit: I'd also add an example and a test with a babel block as it looks like it's a popular setup.

match('.js', [
	eslint(),
	babel(),
])

But we can do it later.

[andywer]

Awesome, thanks for your efforts! 😊

[andywer]

Published as @webpack-blocks/eslint@1.0.0-rc 🚀

[dmitmel]

I've found something wrong in the eslint block: it has @webpack-blocks/core in its peer dependencies.

[andywer]

Might be a copy-pasta mistake. I don't remember with certainty, but I think at some point we added that peer dependency to make explicit that the block only works with webpack-blocks v1 (not v0.x).

It's not critical and the peer dependency is basically true 😉

[dmitmel]

@andywer Nice hack workaround!