Squashing dependency bump commits

[aminya]

There are many numbers of commits on the master that just bump a "@types/" packages that make following the changes very hard. These have created a commit history bloat.

Can we get these squashed?

[UziTech]

I think commit history bloat is a good tradeoff to be able to see when a specific dependency breaks something.

If we do something like bump_deps.yml we need to make sure tests don't have to be run manually and we can exclude certain updates if we need to because it breaks something.

[aminya]

For future updates, I am totally OK with adding a test step. However, I am also interested in squashing the commits that are already on the master branch.

I think the dependency upgrades should be tracked, but when all the updates are going to be landed on a single release that users check, there is no point in having separate commits.

Also, minor updates like @types/ packages are not going to affect the release, so squashing those will not have any effect.

If the commit history is cleaner, we can track the "actual code changes" better.

[UziTech]

If the commit history is cleaner, we can track the "actual code changes" better

I think there are already better ways of tracking actual code changes than looking at commit history, but I am ok with squashing commits before this is released.

[UziTech]

I was just given permission for atom-languageclient and would like to get v1.0.0 released today. Is there anything you would like to do to the code before that?

[aminya]

Great news! Can I squash the dependent bot commits?

We also need to rename the package back to atom-languageclient.

[UziTech]

sounds good 👍

[aminya]

I renamed the repository. Could you make a PR renaming the package itself?

[UziTech]

I created #88 to rename the package. After you squash the commits I'll publish v1.0.0

[aminya]

Squashing done! Closing this.