Remove dist folder, closes #820

[zenflow]

Note this PR is also aimed at the canary branch.

This is inevitable for the next release.

In the meantime this will help to work in Git more easily, in canary and in master too if you base your work off of canary and then rebase it onto master.

[zenflow]

Actually @limonte what if we extended this PR with a script to make a release (a script that would implement this idea of having a dist branch #820 (comment)):

1. ensure Git is on master branch
2. do some sanity checks on packageJson.version (make sure it was updated)
3. delete the dist folder (as it will conflict with the next step)
4. switch to the dist branch
5. merge from master
6. run the build
7. commit the changes in the dist folder
8. tag the commit with v${packageJson.version}
9. npm publish
10. git push origin dist:dist --tags
11. switch back to master so you can continue to work

[zenflow]

This would mean zero changes to how Bower users use our package. We could merge it right into version 7.

[limonte]

Actually @limonte what if we extended this PR with a script to make a release (a script that would implement this idea of having a dist branch #820 (comment)):

ensure Git is on master branch
do some sanity checks on packageJson.version (make sure it was updated)
delete the dist folder (as it will conflict with the next step)
switch to the dist branch
merge from master
run the build
commit the changes in the dist folder
tag the commit with v${packageJson.version}
npm publish
git push origin dist:dist --tags
switch back to master so you can continue to work

This would mean zero changes to how Bower users use our package. We could merge it right into version 7.

Sounds like a perfect solution which will prevent the breaking change! Please create another PR and target the canary branch. After review, we can merge the canary into master.

[zenflow]

Sounds like a perfect solution which will prevent the breaking change!

I'm glad you like it!

After review, we can merge the canary into master.

You mean cut the next major release? We should try populating this project board! https://github.com/sweetalert2/sweetalert2/projects/1

[limonte]

You mean cut the next major release?

Yup. If everything goes as expected users won't have any breaking changes. Without breaking changes we don't need a major bump.

[zenflow]

Oh, yeah. Since canary has already collected a breaking change, we can't merge it into master unless we're cutting a major release. (Which I thought about and then realized I'm crazy since we have no reason to do that right now; it just seemed fun at the time lol)

But it's OK, this branch is based off of master so I just have to add another commit and then we can just also merge it into master. And merge it into canary again.

[zenflow]

Trying to test this before "putting it in production" will be interesting. I'll give it a --dry-run option

[zenflow]

Skipping #s 9 and 10

[zenflow]

so I just have to add another commit and then we can just also merge it into master. And merge it into canary again.

Hmm.. I guess that won't work because the squash-and-merge technically creates a different commit with a different history (but identical code). I undid this merge via 8d982b2 so as not to complicate things further. I'll open a new PR targeting master, and then once it's merged I'll just do the regular "Merge branch 'master' into canary"