Cleanup whitespaces and make it pass with eslint

[satazor]

As the title says.

[faceyspacey]

awesome thanks again. ...do you mind making your commits with npm run commit as per:

https://github.com/faceyspacey/extract-css-chunks-webpack-plugin#contributing

...just make another commit and push to this PR. from the command line menu choose the fix option.

Then when I merge, it's automatically bumped correctly, pushed to NPM, changelogs generated, releases created, etc--all based on commit messages.

[satazor]

Of course, sorry I've missed the contributing section.

[satazor]

Shouldn't the option be style: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc) instead?

[faceyspacey]

this time around sure because I already made a properly named commit on top of ur past PR so it would push to NPM:

https://www.npmjs.com/package/extract-css-chunks-webpack-plugin

...but if I hadn't have done that, only fix, feature and BREAKING CHANGE lead to new code on NPM. So sometimes you gotta label a chore or other as fix so that not just the github repo updates, but also npm.

[satazor]

Does it look good now?

[faceyspacey]

did u do that manually? it didn't format it like it should, eg:

fix($compile): Escape moduleId and css contents + update travis

check my commits here:
https://github.com/faceyspacey/extract-css-chunks-webpack-plugin/commits/master

[satazor]

No, I've used npm run commit. I've chosen style, skip the rest of the questions and entered the title. Perhaps I shouldn't have skipped the scope? What scope should I select? $compile?

[faceyspacey]

i just did a test myself. it seems intentionally formatted like that so as not to trigger a new release. it's why u gotta do fix or feature. those are the only 2 options that bump. On top of that. if you specify breaking change in one of the later command line fields, it will bump the major version.

so fix results in patch bump. feature in minor bump. and if u add a note in the breaking changes field, it does a major version bump.

so just do a fix for now.

[faceyspacey]

also note: force pushing breaks semantic-release, but that might only be on the master branch. so don't do git push --force after rebasing or anything like that. just add a new line at the end of a file and commit that as a fix.

[satazor]

It's fine to --force as long as I'm not on master yea ⚠️

I've chosen fix and skipped scope. Let me know if it's fine.

[faceyspacey]

that should solve it. i guess just starting with fix is all you need. it's missing the scope in parentheses, but it's looking like that won't affect it.

[satazor]

I've skipped scope because I don't know what scope should I write.

[faceyspacey]

in 1 minute we'll know if travis publishes it...

[faceyspacey]

https://travis-ci.org/faceyspacey/extract-css-chunks-webpack-plugin/builds/229640705?utm_source=github_status&utm_medium=notification

[faceyspacey]

success:

https://www.npmjs.com/package/extract-css-chunks-webpack-plugin

nicely done. let me know how everything else goes.

[satazor]

So this is CP aka continuous publishing? :D

[faceyspacey]

pretty much lol. ...not the best for this package, but my other packages have tight tests (usually near 100% test coverage)...but yea semantic-release + commitizen is all about CP. They're also all about true semantic versioning, which might lead to major versions changing often (i.e. for every breaking change), but the idea is if followed doesn't break people's apps who mostly use the caret ^ to pin at a minor version.

Basically the one downside is it's bad for marketing if you only want to have a 1.0, 2.0 etc every so often. React Router got shit recently as you probably saw for all the major versions they went through in such a short period of time. Honestly, I plan for my latest packages to go through way more versions if necessary, and just let people know what to expect. I don't care about only bumping major versions every 1 or 2 years for marketing; i rather follow semantic versioning properly (or at least my understanding of it). In addition, greenkeeper really helps u out by keeping your packages up to date--so if ur using that, it solves the problem of u being pinned at an old major version for a long time.

[satazor]

I think the ideal solution is a mid ground. Bumping major versions too fast can actually decrease the popularity of the library because it requires too much maintenance burden for consumers, even with greenkeeper. So I think that when a breaking change occurs or is committed into the master, we should aggregate other breaking changes and updates to "buffer" everything and have it all in one go.

[faceyspacey]

totally agree. at the end of the day that's the plan--use some elbow grease to minimize major bumps...create a next branch and use dist-tags (https://docs.npmjs.com/cli/dist-tag) to promote the new release.

...it's not documented well in semantic-release but I figured out how to have a next git branch and have releases published just to its corresponding dist-tag of the same name, while having your master publish to the latest dist-tag...basically in the config (which lives in package.json) you specify which branch can trigger publishes, and obviously in each branch maintain a different config in the package.json.

The result is if you got a 4.0 next dist-tag and a 3.0 latest dist-tag. Any publishes to the 4.0 will be associated with its dist-tag (and continue to bump it, eg: 4.0.1), whereas if anyone downloads ur package they get the latest 3.0.