1.0 release

[andywer]

Hi everyone! This is gonna be the "1.0 release issue", showing the big picture, in contrast to the many small issues.

Version number change

Since webpack 1.x has officially been deprecated I am now fine with releasing the next webpack-2-only major version as webpack-blocks 1.0. So if you find references to a 2.0 release, this will actually be the 1.0 release.

Changes

• Webpack 2 only, drop duplicate packages (like extract-text and extract-text2) Remove webpack 1.0 elements for 2.0 branch #127
• Use module.rules syntax module.loaders is now module.rules #111 Port to webpack 2.0 config style #124
• Implement new API: API for version 1.0 #125
• Decide if the new API and its util parameter are fine or should be changed API for version 1.0 #125
• Drop release/1.0 branch, rename release/2.0 => release/1.0
• Make createConfig.vanilla() the new createConfig()
• Create a new package with CSS, font, image, ... loaders (because of the change above)
• Make sure that different CSS loaders work seemlessly with node_modules exclusion Build fails when set exclude option for CSS Modules and/or PostCSS #133
• Improve sass + extract-text documentation SASS block + ExtractText2 block #115
• Move extract-text config logic into post hook
• Update loader/plugin versions
• Webpack as peerDependency & support webpack 3 Migrate V1.0 to webpack 3 #167
• List contributors
• Merge Cannot use extractText block to produce html files #117
• Merge master
• Don't forget to inform 3rd party block maintainers in time (!)

(Not necessarily in that order 😉)

Nice to have

• Create package that wraps all the most common packages, so user does not have to manage dozens of single webpack-blocks packages
• Check which parts of webpack-parts might be merged into webpack-blocks Merging webpack-parts into webpack-blocks #122
• Check if SASS works together with CSS modules SASS + CSS modules #130
• Create a preset for basic asset loaders (since they won't be set up automatically anymore)
• Make code use node 6+ features, drop inconsistent use of transpiling 1.0 release: Drop support for node < 6 #146

@eXon @jvanbruegge @sapegin @aaronjensen

[andywer]

Sorry for shooting ahead, but since we already had the discussion about 1.0/2.0 I figured there is not much sense in riding the now-deprecated horse much further.

You guys agree with the short summary of the 1.0 release?

[jvanbruegge]

I would add that extract text should use a post hook to work automaticly with sass (so you dont need to document anything). Would make order of sassBlock and extract-text block irrelevant

[andywer]

Good point!

[aaronjensen]

This looks good to me. I probably wouldn't rebase onto master at this point (too much risk, merge is safer and maintains history) but that's a workflow nit. I'm very 👍 on webpack 2 only.

[andywer]

True! Updated the list :)

[andywer]

Update: "Make createConfig.vanilla() the new createConfig()" and "Create a new package with CSS, font, image, ... loaders" are almost done 🎉

Idea: Now that the next LTS release of node is about to be released it might be time to drop support for node < 6.0. Would allow us to drop Babel which is not used consistently.

Objections?

[aaronjensen]

None from me 👍

[jvanbruegge]

None from me either. Destructuring makes code nicer :)

[andywer]

Just added a bullet point to "nice to have": Create package that wraps all the most common packages, so user does not have to manage dozens of single webpack-blocks packages

This is an idea I had in my mind for some weeks now: The modularity of webpack-blocks is a nice feature, but having to manage a dozen @webpack-blocks/* devDependencies may be cumbersome and does not look too elegant. So a package that exports all the most common blocks might be a nice solution.

+ const { createConfig, env, entryPoint, setOutput, sourceMaps, css, file, babel, devServer } = require('webpack-blocks')
- const { createConfig, env, entryPoint, setOutput, sourceMaps } = require('@webpack-blocks/webpack')
- const { css, file } = require('@webpack-blocks/assets')
- const babel = require('@webpack-blocks/babel6')
- const devServer = require('@webpack-blocks/dev-server')

module.exports = createConfig([ /* ... */ ])

{
  "devDependencies": {
+   "webpack-blocks": "^1.0.0",
-   "@webpack-blocks/assets": "^1.0.0",
-   "@webpack-blocks/babel6": "^1.0.0",
-   "@webpack-blocks/dev-server": "^1.0.0",
-   "@webpack-blocks/webpack": "^1.0.0",
    "webpack": "^2.0.0"
  }
}

Fewer dependencies in the app, less effort keeping block versions in sync (e.g. @webpack-blocks/webpack v1.0 together with @webpack-blocks/dev-server v0.4 will crash), easier to switch to new major versions.

Could also be added after the 1.0 release, though. And maybe it should be, since there are still more important things left to do.

[jvanbruegge]

Yes, this may also increase adoption, because simply from a psychological view a single dependency is less scary than a dozend

[stevenjlho]

This is a nice feature.

[Wenqer]

@andywer i suggest to stay babel in the separate package, because not all web devs use it now, for example: typescript devs, electron devs, guys who support only latest versions of chrome/firefox

[jvanbruegge]

It does not matter if it is included or not. Just dont use it. It's a devDependency, so size is not a problem.
I would include all official blocks.

[andywer]

@Wenqer @jvanbruegge You both got valid points, but I'd say the truth lies somewhere in between. We should ship many of the official blocks, because otherwise it won't be very useful and as Jan pointed out, dev dependencies' size does not matter much.

On the other hand I would probably not want to include the elm block, for instance, since it will install quite a lot of stuff that the majority of people won't use.

I suggest including both the babel and typescript block. Otherwise it's going to be neither of them (that would be sad) or a decision React vs Angular 😉

[jvanbruegge]

Ok, yeah I agree, didn't think of the elm block

[andywer]

A few quick npm publish for me, but a big step forward for webpack-blocks:

The alpha version of webpack-blocks v1.0 is published! 🎉

Install using npm install --save-dev @webpack-blocks/webpack@next ... or using the new convenience package npm install --save-dev webpack-blocks@next.

Give it a try and report any issues you might encounter. Should be fairly stable for an "alpha", though 😉

Remember that there were breaking changes in the core API. All blocks in this repo have been updated, but third-party blocks or your custom blocks won't work until they are updated as well.

[jvanbruegge]

Maybe tick the assets block and the convenience block in your list :)

[andywer]

Ohh, of course :)

I won't tick the assets preset, since there is the block, but not a preset. Btw, I am not sure if we actually need a preset for that.

[andywer]

Pinging @bkonkle, @diegohaz, @foxbunny, since they will need to update their blocks. But don't worry, this is like a first official heads-up. A short migration guide will follow (don't worry, it's not hard to update).

[bkonkle]

Thanks for the advance warning!

…

-- Brandon Konkle Phone: (720) 239-2573 Twitter:  http://twitter.com/bkonkle http://ecliptic.io/ On Mon, May 08, 2017 at 10:09 AM Andy Wermke < mailto:Andy Wermke <[email protected]> > wrote: a, pre, code, a:link, body { word-wrap: break-word !important; } Pinging https://github.com/bkonkle , https://github.com/diegohaz , https://github.com/foxbunny , since they will need to update their blocks. But don't worry, this is like a first official heads-up. A short migration guide will follow (don't worry, it's not hard to update). — You are receiving this because you were mentioned. Reply to this email directly, #134 (comment) , or https://github.com/notifications/unsubscribe-auth/AAB196MV0uL1IftM40-W9_h0D62IDmnyks5r3z4qgaJpZM4Mdq-h .

[foxbunny]

@andywer I see there are now somewhat non-essential blocks like elm block. What is the official policy regarding contributed blocks? Is it preferred that developers contribute to this repository, or maintain their own? (I'm referring to blocks like vue, riot, or whatever frameworks and technologies people may wish to support.)

[andywer]

@foxbunny Good question. My current approach is:

Open a PR if you think the block is worth being put in the official repository and we will have a look at it and decide if it makes sense to merge 😉

Generally I'd say that most framework-related blocks are probably not supposed to be part of the official repo, except for maybe very popular React or Angular stuff, since they are very dominant.

Elm is on the edge of what I'd say should be part of the main repo. But everything is discussable :)

I hope that clarifies things at least a little bit!

[foxbunny]

Alright, sounds good.

[dmitmel]

Is there any progress on this release?

[andywer]

We should ship it!

I don't see any blockers. Better docs would be nice, but shouldn't block the release.

[stevenjlho]

I think we shouldn’t add more feature before 1.0 release. And improve document detail.

[dmitmel]

We should ship it!

@andywer Is the 1.0 release ready to be published to NPM?

[andywer]

I think v1.0 is ready to be published.

TypeScript typings would be really nice to have, but who knows how the long that will take (and I have very little time at the moment).

@ALL Does anyone see a reason not to release v1.0?

[dmitmel]

@andywer I think it's time to finally release v1.0 and to start working on v2.0.

[zcei]

I'm still up for providing some first typings as soon as we've settled for naming we want to proceed with.
Until then: release the v1.0

[andywer]

Left a comment in the typings issue.

Yeah, I should just block some time later this week and v1.0.
I would schedule it for release on Thursday night (so round about 19:00 UTC).

[andywer]

Release v1.0 has been published! 🚀

Read the release notes here. Big thanks to all of you! We did this together 😊

[dmitmel]

@andywer webpack-blocks is the first project on GitHub I've ever contributed to!

[andywer]

@dmitmel Ohh really? That's great! 🙌

[zcei]

Awesome 👏