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 😒