Feature: consider moving js-client deploy logic to the CLI

[erezrokah]

At the moment most of the CLI deploy command logic in handled by the js-client:

js-client/src/deploy/index.js

Line 42 in 9d3945c

const { fnDir, configPath, statusCb, message: title } = opts

This seems out of place for a client that should be wrapping our open-api spec.
Also, it prevents this client from being browser compatible.

It might makes sense to move that logic to the CLI, since we're already implementing some deploy logic in the CLI as a part of edge handlers:
netlify/cli#1244

[ehmicky]

💯

[erezrokah]

Doing this would also allow for better error handling as we could try/catch on each deploy related operation instead of catching everything here:
https://github.com/netlify/cli/blob/7db9ce56c26d25ca43631daaf5d32c3140e15f6a/src/commands/deploy.js#L228

[svdoever]

Please don't - I want to use the deploy logic of this library within my own application but NOT depend on netlify-cli. I'm running within a cramped VM with 200 MB diskspace (using https://glitch.com), so could NOT use netlify-cli, because installing that package downloads 75MB (mostly due to typescript - Why?!):

$ npm ls typescript
netlify-test@1.0.0 /mnt/c/Users/serge/Downloads/netlify
└─┬ netlify@4.9.0
  └─┬ @netlify/zip-it-and-ship-it@1.4.0
    └─┬ precinct@6.3.1
      └─┬ detective-typescript@5.8.0
        └── typescript@3.9.7

Top 5 package sizes in netlify-dev:

$ du -sh -BK ./node_modules/* | sort -nr
53240K  ./node_modules/typescript
2304K   ./node_modules/lodash
1984K   ./node_modules/@babel
1928K   ./node_modules/string.prototype.trimstart
1928K   ./node_modules/string.prototype.trimend

That TypeScript is big, ok, but trimstart 2MB, and trimend 2MB... wow!

I just see that there is actually the same problem with the current netlify/js-client library which depends on the same stuff, so not useable as well!!! Such a pity...

And about netlify-cli, it even downloads all versions of the traffic-mesh-agent (windows, linux, osx), another whooping 90MB!

By the way... just looked up the actual implementation of trimEnd() (package string.prototype.trimstart) and trimStart() (package string.prototype.stringend) - good for 4MB in the package:

trimStart():

'use strict';

var callBind = require('es-abstract/helpers/callBind');
var replace = callBind(String.prototype.replace);

/* eslint-disable no-control-regex */
var startWhitespace = /^[\x09\x0A\x0B\x0C\x0D\x20\xA0\u1680\u180E\u2000\u2001\u2002\u2003\u2004\u2005\u2006\u2007\u2008\u2009\u200A\u202F\u205F\u3000\u2028\u2029\uFEFF]*/;
/* eslint-enable no-control-regex */

module.exports = function trimStart() {
	return replace(this, startWhitespace, '');
};

trimEnd():

'use strict';

var callBound = require('es-abstract/helpers/callBound');
var $replace = callBound('String.prototype.replace');

/* eslint-disable no-control-regex */
var endWhitespace = /[\x09\x0A\x0B\x0C\x0D\x20\xA0\u1680\u180E\u2000\u2001\u2002\u2003\u2004\u2005\u2006\u2007\u2008\u2009\u200A\u202F\u205F\u3000\u2028\u2029\uFEFF]*$/;
/* eslint-enable no-control-regex */

module.exports = function trimEnd() {
	return $replace(this, endWhitespace, '');
};

Combine those two and you are under 200 bytes:-) It is a crazy world....

[erezrokah]

Thanks for your input @svdoever. See more about package size here netlify/cli#494

[eduardoboucas]

Currently, CLI works with two instances of zip-it-and-ship-it: one as a direct dependency and another as a transitive dependency via netlify (the package published from this repo). This is not ideal and introduces unnecessary complexity and maintenance overhead.

Moving the bundling logic to CLI would consolidate them into one, while at the same time simplifying the netlify package, making it simply a wrapper over our Open API spec, as @erezrokah pointed out.