2.0 roadmap

[vlad-zhukov]

Hello! I'm interested to release a v2.0 as soon as possible and I've got an approval from other maintainers to work on it on our gitter! (Join it if you haven't yet!)

---

This is going to be a breaking, webpack-4-only release, that updates the block API and drops deprecated ones. We also aim to make lots internal changes to make further maintaining much easier and beginner friendlier!

All new changes should go into the release-2.0 branch (#266), while master stays the same and represents the current stable release (v1.0).

TODO

• Migrate to webpack 4 (tracking issue Support for webpack 4 #255).
• Consider updating to babel@7.
• Remove the deprecated fileType API (PR Remove the old fileType API #260).
• Remove the deprecated resolveAliases block. (PR Remove deprecated resolveAliases block #267)
• Use yarn workspaces (PR Use yarn workspaces #268).
• Decide to either upgrade lerna or use something else (see discussion in Upgrade lerna setup #236).
• Remove ava from devDeps of every package and hoist it to the root. (PR Hoist ava to the root #276).
• Use prettier (PR Replace standard with prettier #263 Prettier #275).
• Consider adding some eslint code rules (not style ones).
• Other minor changes left in 2.0.0 Milestone.
• Cut a branch 1.0.0 from master before merging release-2.0.
• List contributors!

Removed from 2.0 release scope

• Update the block API (see discussion in API for version 1.0 #125, PR API for version 2.0 #259).
• Consider moving unpopular blocks to the webpack-blocks org (issue Move unpopular blocks to the webpack-blocks org #269).
• Add TypeScript definitions (issue Add tsd #246, PR Add TypeScript typings for core & webpack #247).
• Write a migration guide.
• Inform 3rd-party block maintainers!

@andywer @jvanbruegge @zcei @dmitmel @marcofugaro

[dmitmel]

Consider updating to babel@7.

@vlad-zhukov See #257

[vlad-zhukov]

@dmitmel I really want this to happen because I use babel 7 myself since alphas. But they keep making breaking changes in betas and suggest to pin exact versions themselves, which is fine for an app but absolutely not fine for a library. Once they announce there are not going to be breaking changes anymore (probably in rcs), we can update the block. But for now it's going to wait for some time.

[vlad-zhukov]

I've created a release-2.0 branch, all new changed should target it instead of the master.

[dmitmel]

@vlad-zhukov babel-core is a peer dependency so our users can decide what version of Babel they want to use.

[vlad-zhukov]

@dmitmel but Babel 7 requires @babel/core instead. Anyway, can we leave the babel upgrade for a while now please for the reason I pointed above? It's not difficult to upgrade the block itself (simply bump babel-loader to v8 and use @babel/core instead of babel-core as a peer dependency), but it's not ready to be upgraded yet and we have more important stuff to do.

I would like to focus on internal changes first, such as cut build sizes as much as possible (15min CI builds are terrible) and use of prettier. This will make our life easier and we will be able to make block upgrades faster.

[dmitmel]

@vlad-zhukov OK, we can upgrade to Babel 7 after v2.0

[farism]

One suggestion I would make would be paring this list down to just breaking changes. Some of it is fluff that is not required for V2 and can be slated as followups. And getting on Webpack 4 is imo the end goal. The following list is what I think are the necessary todos for a V2 beta:

Migrate to webpack 4 (tracking issue #255).
Updating to babel@7.
Update the block API (see discussion in #125, PR #259).
Remove the deprecated fileType API (PR #260).
Remove the deprecated resolveAliases block. (PR #267)
Use yarn workspaces (PR #268) (this was merged today)
Cut a branch 1.0.0 from master before merging release-2.0 (this is already done I think?)
Write a migration guide.
Inform 3rd-party block maintainers!

[andywer]

Fair enough. Consider moving unpopular blocks to the webpack-blocks org or Add TypeScript definitions, for instance, are non-breaking. They could be done before or after v2 if need be.

[zcei]

If I know remove the whole ./packages/elm folder, we might get some rebase problems, as other commits - like yarn workspaces - touches it.

@vlad-zhukov would you be okay with rebasing the release-2.0 branch. or shall I file the PR against v2? If the latter, we need to keep in mind to sync changes between the standalone- and the monorepo 😒

[vlad-zhukov]

@zcei Nice job! File a PR against v2 please, the master branch is not going to have any major changes.

Could you also move a test from packages/webpack/__e2e-fixtures__/elm?

[zcei]

the master branch is not going to have any major changes.

"Major" as in "no semver major" or in "no substantial changes"? As @andywer mentioned, it's technically not breaking for the packages. But I'm happy to open it against v2.

Damn, I was remembering the e2e fixture when I started off, but then forgot about it again, thanks 🤦‍♂️

[vlad-zhukov]

No substantial changes or even no changes at all. The plan is to release v2 ASAP.

[marcofugaro]

Hey, how is the 2.0 progress going?

@andywer mind releasing another alpha version? 🙏

[andywer]

I am very busy with other things right now, unfortunately. And it seems like so are many of my fellow contributors.

How about publishing a 2.0 release candidate and postponing everything that's not a blocker to be done after the 2.0 release?

I fear otherwise we will never get anywhere. Let's be pragmatic :)

[marcofugaro]

Any updates?

[andywer]

@marcofugaro Thanks for the reminder. Unfortunately I have been super busy the last days and before I didn't give it the priority it deserves, since no one seemed to be pushing for it.

[andywer]

@ALL Can the community please help out on this one?

-> Are there any blockers left to unblock or can we go for the 2.0 release straight away?

[dmitmel]

@andywer I don't see any reasons why we shouldn't. Webpack 4 support is not a nice-to-have feature anymore, it's a requirement.

[andywer]

Webpack 4 support is not a nice-to-have feature anymore, it's a requirement.

Most definitely. The question is just whether there are any items on the original 2.0 roadmap that we shouldn't carelessly skip.

[dmitmel]

Here are my thoughts:

Update the block API (see discussion in #125, PR #259).

Add TypeScript definitions (issue #246, PR #247).

Consider moving unpopular blocks to the webpack-blocks org (issue #269).

IMO these are not essential parts of the 2.0 release, they have only been slowing it down so far.

Write a migration guide.

Inform 3rd-party block maintainers!

We don't need to do this if we don't change the block API.

List contributors!

If this is required, I can do it on the weekends.

[andywer]

Thx, @dmitmel! Sounds like we can release straight away then.

Shouldn't make much difference if we do the list first and release then or the other way around. Main thing is just that we have one.

Maybe we can just link to Insights > Contributors for now. Will only recognize the commits people made, not their non-code contributions like discussions, feedback, etc. Might be ok as a first step?

[SavePointSam]

It may also be worthwhile to integrate https://github.com/all-contributors/all-contributors if you're really wanting to recognize everyone, although I'm unsure of it's retroactive listing ability. It sure does make it easier to add people. You could probably just install it and then quickly add everyone from the insights as a baseline.

[dmitmel]

@andywer I guess we can finally merge release-2.0 into master and publish v2.0

[andywer]

Just merged the 2.0 branch into master and published version 2.0.0-rc under the latest tag, so it will be the default version to be installed from now on 🚀

[andywer]

Version 2.0.0 is out now. Basically the same as 2.0.0-rc, but with some fixed peer dependency versions.

🚀

[andywer]

Anyone in the mood to draft some release notes for v2.0.0?

I'm so sorry, but I got so little time to spend on webpack-blocks right now... A community effort would be awesome 😊