Shipit v4.0.0

[gregberge]

Hello,

First, I am sorry, I was absent from the project for a long time. Even if @timkelty did a very great job, the project was not actively maintain. Now I am back as the main maintainer on the project. I will try to make Shipit evolve fast and in the right way.

This goal of this issue is to describe and follow the next release of Shipit : v4.0.0.

Global

• Use lerna to handle multiple packages in the same repository

shipit-cli

Features

• Improve Shipit cli utilities Extend shipit cli util #75
• Support ES6 modules in shipitfile.babel.js
• Give access to raw config Consider config/environment changes (2.0) #93
• Standardise errors Consider having shipit.local promise reject with the same object as the resolve #154

Bugs

• Fix usage of user directory Fix cwd #160
• Fix SSH key config Ignores SSH key config shipit-deploy#151 SSH Key issue shipit-deploy#126

Refactoring and chores

• Rewrite project in ES2017 targeting Node.js v6+

Breaking changes

• Drop callbacks support and use native Promises

Docs

• Improve documentation Fix link in readme #69 Clarify "workspace" option. #148 Proposal: Recipe directory #81

ssh-pool

Features

• Introduce a "tty" option in "run" method Problems with interactive SSH #56
• Support "cwd" in "run" command Add cwd option in remote command #9
• Expose a "isRsyncSupported" method

Bugs

• Fix parallel issues using scp copy copyViaScp cause I/O error with parallel copying ssh-pool#22
• Fix command escaping Escaping commands for shipit.remote/local #91 How can I stop local env var expansion when using shipit.remote #152

Deprecation for v3

• Deprecate automatic "sudo" removing when using "asUser" Problems with interactive SSH #56 Make TTY optional #12
• Deprecate "copy" method in favor of "copyToRemote", "copyFromRemote",
  "scpCopyToRemote" and "scpCopyFromRemote"
• Deprecate using "deploy" as default user
• Deprecate automatic "tty" when detecting "sudo" Problems with interactive SSH #56

Breaking changes

• Drop callbacks support and use native Promises
• Standardise errors Consider having shipit.local promise reject with the same object as the resolve #154
• Replace "cwd" behaviour in "run" command Add cwd option in remote command #9

Refactoring & Chores

• Rewrite project in ES2017 targeting Node.js v6+
• Use Jest for testing
• Add Codecov

Documentation

• Update readme with new documentation

shipit-deploy

Bugs

• Use [ instead of [[ to improve compatiblity bashism in updateSymbolicLink shipit-deploy#147 Use [ instead of [[ shipit-deploy#148
• Use rmfr to improve compatibility Fix workspace cleaning on Windows. shipit-deploy#135 Use rimraf for cross platform compatibility shipit-deploy#155

Breaking changes

• Default shallowClone to true
• Drop grunt-shipit support
• Workspace is now a temp directory in shallow clone
• An error is thrown if workspace is set to the current directory

Refactoring & Chores

• Rewrite project in ES2017 targeting Node.js v6+
• Use Jest for testing
• Add Codecov

Documentation

• Update readme with new documentation

[timkelty]

@neoziro Have you considered setting up v4 as a Lerna monorepo? Could make development and releases easier.

[gregberge]

@timkelty yep I was thinking about it. I don't know if we should do it in v4 or v5. It will be my first project using Lerna, I do not have any experience with it.

[gregberge]

@timkelty I will finally switch to Lerna for v4. https://github.com/shipitjs/shipit/tree/v4.0.0

[timkelty]

@neoziro sounds good to me!

[timkelty]

Great to see the project gaining traction again and have @neoziro back.

Here are some of my thoughts & ideas for v4:

Task Orchestration

• Do we need a 3rd party task manager at all? (Should we just use node events/EventEmitter)?
• Orchestrator seems dead…consider using https://github.com/gulpjs/undertaker as a replacement?

Packages/repo

Great to see Lerna, I think think that will make development a lot easier.

Wondering if we should split shipit and shipit-cli. This would allow an alternate cli to still use Shipit internals (e.g. https://github.com/timkelty/shipit-captain).

Configuration (Shipitfile)

ES6 support 👍 love it!

Shipit.initConfig seems clumsy and not really necessary (possibly a relic from old Grunt implementation?). Seems simpler to just interact with Shipit.config, e.g.

module.exports = shipit => {
  Object.assign(shipit.config, {
    deployTo: '…'
    /* etc */
  });
}

Furthermore, for users that don't require alot of customizations or task definitions, we could also support just a config object:

module.exports = {
  deployTo: '…'
  /* etc */
}

I've been using Neutrino for webpack configuration for bit, and this is how the .neutrinorc.js file works. It works quite well. Simple when you want it to be, extensible when you need it.

Along those same lines, I think we should implement a Shipit.use method and option to avoid loading tasks like require('shipit-deploy')(shipit).

The result would be much simpler and easier to digest:

Simple version

module.exports =  {
  use: ['shipit-deploy', 'shipit-shared'],
  deployTo: '…'
  /* etc */
}

const deploy = require('shipit-deploy');
const shared = require('shipit-shared');

module.exports = shipit => {
  Object.assign(shipit, {
    deployTo: '…'
    /* etc */
  });

  shipit.use(deploy, shared);

Task options

I think we need a formalized way for tasks to have options. Until now, I've been just piggybacking off a similarly named key in shipit.config, but this seems like a bad idea.
shipit.use would come in here again:

shipit.use(require('shipit-deploy'), {/* my options for shipit-deploy */});

[gregberge]

@timkelty thanks for your ideas! I want to minimize changes for v4, just a refactoring, some deprecations and a new start for the project. No big breaking changes.

Do we need a 3rd party task manager at all? (Should we just use node events/EventEmitter)?

Nop, we should drop it.

Orchestrator seems dead…consider using https://github.com/gulpjs/undertaker as a replacement?

Yes of course.

Wondering if we should split shipit and shipit-cli. This would allow an alternate cli to still use Shipit internals (e.g. https://github.com/timkelty/shipit-captain).

Yes it makes sense, shipit-core is available.

Shipit.initConfig seems clumsy and not really necessary (possibly a relic from old Grunt implementation?). Seems simpler to just interact with Shipit.config, e.g.

We can discuss the API, but mutating config is not a good solution.

Furthermore, for users that don't require alot of customizations or task definitions, we could also support just a config object:

I don't think it's a game changer and we should minimize the API surface.

Along those same lines, I think we should implement a Shipit.use method and option to avoid loading tasks like require('shipit-deploy')(shipit).

Yes we should make it easier to add plugins.

I think we need a formalized way for tasks to have options. Until now, I've been just piggybacking off a similarly named key in shipit.config, but this seems like a bad idea.
shipit.use would come in here again:

Yes plugins should have a reserved namespace it makes sense.

[timkelty]

Yep, I figured. Just wanted to get some ideas recorded. 👍

[gregberge]

Version 4 is released 🎉 👯

[timkelty]

Great work @neoziro!

[gregberge]

@timkelty thanks!