Self-improving Software

Dr. Gleb Bahmutov PhD

Kensho Boston / NYC

App Assembly

Auto part = Node Package

{
  "name": "my-module",
  "version": "0.1.0",
  "git": ...,
  "dependencies": {
    "foo": "0.1.*",
    "bar": "~1.2.0",
    "baz": "^2.0.1"
  },
  "devDependencies": {
    "grunt-concat": "0.1.1"
  }
}

Eliminate surprises

Use exact versions

$ npm config set save-exact true
$ npm install --save-exact grunt-nice-package
// cleans up fuzzy symbols

grunt-nice-package

Worry about the top level.

1.5.0

4.0.1

Semantic versioning

major . minor . patch

unicorns . stars . angels

semver.org

really

major . minor . patch

major' . minor' . patch'

From:

To:

Semantic versioning

semver.org

  • major: I broke it

  • minor: I added new feature

  • patch: I fixed something

really

Semantic versioning

semver.org

Problem: out of date

// package.json
{
    "dependencies": {
        "module-a": "1.0.0"
    }
}
// npm registry:
module-a: 0.8.0, 0.9.0, 1.0.0, 1.0.1, 2.0.0

david-dm

Q: Can I upgrade?

// package.json
{
    "dependencies": {
        "module-a": "1.0.0"
    }
}
// npm registry:
module-a: 0.8.0, 0.9.0, 1.0.0, 1.0.1, 2.0.0

A: No one knows

// package.json
{
    "dependencies": {
        "module-a": "1.0.0"
    }
}
// npm registry:
module-a: 0.8.0, 0.9.0, 1.0.0, 1.0.1, 2.0.0

Relying on human-supplied semver is like relying on human-typed code comments to be 100% accurate

autointegrate using next-update

next-update

watch

next-update

next-update

watch

What am I getting?

changed-log

watch

next-update-stats

next-update-stats

next-update-stats

next-update-stats

Semver adherence

Measuring semver adherence

Semver adherence

Measuring semver adherence

Semver adherence

lodash respects semver

underscore and Ramda do not

* Ramda is still 0.15.0 (< 1.0.0)

next-updater

autointegrate ALL projects

using next-updater

Automate SemVer - the opposite of next-update

We fail to follow SemVer – and why it needn’t matter by Stephen Bonnemann (JSConf Budapest 2015)

Test each code against its own

previous tests

semantic-release

Q: Are you going to break everyone?

dont-break

dont-break from module X

  1. Install each dependent project

  2. Replace X@x.y.z with X@current

  3. Run unit tests 

If we are breaking dependent projects - maybe we should increment MAJOR in semver major.minor.patch

dont-break from module X

Conclusions

  1. Know what you are getting: changed-log, next-update-stats

  2. Test your software against the world: dont-break, semantic-release
  3. Upgrade versions without breaking stuff: next-update / next-updater

Self-improving Software

Companion blog posts: Dependencies for NodeJs, modular development

Dr. Gleb Bahmutov PhD

Kensho Boston / NYC

Self-improving Software

Dr. Gleb Bahmutov PhD

Kensho Boston / NYC

Companion blog posts: Dependencies for NodeJs, modular development

Self-improving software NYC NodeJS meetup

By Gleb Bahmutov

Self-improving software NYC NodeJS meetup

Any JavaScript project requires 3rd party modules. As soon as you depend on specific versions, your module falls behind. I will show how to keep your software up to date without any effort (as long as there are some tests). You can automatically upgrade dependencies for an individual project, a collection of projects. You can even see the anonymous version upgrade results across the public projects around the world to judge if a particular update is likely to succeed. What about projects that depend on your software? Before releasing a new version, you can test some or all of your dependencies against the new code.

  • 5,740

More from Gleb Bahmutov