Git Product home page Git Product logo

js-client's Introduction

!important Notice

This repository was moved into the mono repository of github.com/netlify/build The package name and the versions are preserved!

netlify/js-client

npm version build status coverage dependencies downloads

A Netlify OpenAPI client that works in the browser and Node.js.

Usage

import { NetlifyAPI } from 'netlify'

const client = new NetlifyAPI('1234myAccessToken')
const sites = await client.listSites()

Using OpenAPI operations

import { NetlifyAPI } from 'netlify'

const client = new NetlifyAPI('1234myAccessToken')

// Fetch sites
const sites = await client.listSites()

// Create a site. Notice `body` here for sending OpenAPI body
const site = await client.createSite({
  body: {
    name: `my-awesome-site`,
    // ... https://open-api.netlify.com/#/default/createSite
  },
})

// Delete site. Notice `site_id` is a path parameter https://open-api.netlify.com/#/default/deleteSite
await client.deleteSite({ site_id: siteId })

API

client = new NetlifyAPI([accessToken], [opts])

Create a new instance of the Netlify API client with the provided accessToken.

accessToken is optional. Without it, you can't make authorized requests.

opts includes:

const opts = {
  userAgent: 'netlify/js-client',
  scheme: 'https',
  host: 'api.netlify.com',
  pathPrefix: '/api/v1',
  accessToken: '1234myAccessToken',
  agent: undefined, // e.g. HttpsProxyAgent
  globalParams: {}, // parameters you want available for every request.
  // Global params are only sent of the OpenAPI spec specifies the provided params.
}

client.accessToken

A setter/getter that returns the accessToken that the client is configured to use. You can set this after the class is instantiated, and all subsequent calls will use the newly set accessToken.

client.basePath

A getter that returns the formatted base URL of the endpoint the client is configured to use.

OpenAPI Client methods

The client is dynamically generated from the OpenAPI definition file. Each method is is named after the operationId name of each operation. To see a list of available operations, please see the OpenAPI website.

Every OpenAPI operation has the following signature:

response = await client.operationId([params], [opts])

Performs a call to the given endpoint corresponding with the operationId. Returns a promise resolved with the body of the response, or rejected with an error with the details about the request attached. Rejects if the status > 400.

  • params is an object that includes any of the required or optional endpoint parameters.
  • params.body should be an object which gets serialized to JSON automatically. Any object can live here but refer to the OpenAPI specification for allowed fields in a particular request body. It can also be a function returning an object.
  • If the endpoint accepts binary, params.body can be a Node.js readable stream or a function returning one (e.g. () => fs.createReadStream('./foo')). Using a function is recommended.
// example params
const params = {
  any_param_needed: anyParamNeeded,
  paramsCanAlsoBeCamelCase,
  body: {
    an: 'arbitrary js object',
  },
}

Optional opts can include any property you want passed to node-fetch. The headers property is merged with some defaultHeaders.

// example opts
const opts = {
  headers: {
    // Default headers
    'User-agent': 'netlify-js-client',
    accept: 'application/json',
  },
  // any other properties for node-fetch
}

All operations are conveniently consumed with async/await:

try {
  const siteDeploy = await client.getSiteDeploy({
    siteId: '1234abcd',
    deploy_id: '4567',
  })
  // Calls may fail!
} catch {
  // handle error
}

If the response includes json in the contentType header, fetch will deserialize the JSON body. Otherwise the text of the response is returned.

API Flow Methods

Some methods have been added in addition to the open API operations that make certain actions simpler to perform.

accessToken = await client.getAccessToken(ticket, [opts])

Pass in a ticket and get back an accessToken. Call this with the response from a client.createTicket({ client_id }) call. Automatically sets the accessToken to this.accessToken and returns accessToken for the consumer to save for later.

Optional opts include:

const opts = {
  poll: 1000, // number of ms to wait between polling
  timeout: 3.6e6, // number of ms to wait before timing out
}

See the authenticating docs for more context.

import open from 'open'

const ticket = await client.createTicket({ clientId: CLIENT_ID })
// Open browser for authentication
await open(`https://app.netlify.com/authorize?response_type=ticket&ticket=${ticket.id}`)

// API is also set up to use the returned access token as a side effect
// Save this for later so you can quickly set up an authenticated client
const accessToken = await client.getAccessToken(ticket)

Proxy support

Node.js only: If this client is used behind a corporate proxy, you can pass an HttpsProxyAgent or any other http.Agent that can handle your situation as agent option:

import HttpsProxyAgent from 'https-proxy-agent'

const proxyUri = 'http(s)://[user:password@]proxyhost:port'
const agent = new HttpsProxyAgent(proxyUri)
const client = new NetlifyAPI('1234myAccessToken', { agent })

Site deployment

Support for site deployment has been removed from this package in version 7.0.0. You should consider using the deploy command of Netlify CLI.

Contributing

See CONTRIBUTING.md for more info on how to make contributions to this project.

License

MIT. See LICENSE for more details.

js-client's People

Contributors

bcomnes avatar biilmann avatar calavera avatar cassidoo avatar davidwells avatar dependabot[bot] avatar dustincrogers avatar eduardoboucas avatar ehmicky avatar erezrokah avatar fool avatar github-actions[bot] avatar ingride avatar jgantunes avatar keiko713 avatar leonardodino avatar netlify-bot avatar polemius avatar raeesbhatti avatar ramigs avatar renovate-bot avatar renovate[bot] avatar rkretzschmarkaiser avatar rstacruz avatar ruemic avatar swyxio avatar tobiaslins avatar token-generator-app[bot] avatar tzmanics avatar xhmikosr avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

js-client's Issues

Possible typo in README.md

- Do you want to request a feature or report a bug? Bug

- What is the current behavior?
Readme.MD tells about optional parameters "parallelUpload" and "paralellHash" but in src/deploy/index.js the parameters are named "concurrentHash" and " concurrentUpload".

- If the current behavior is a bug, please provide the steps to reproduce.
Review the README.md:
https://github.com/netlify/js-client/tree/6070f83a528eb4685c10764c1bd9716b80a07935

Compare it to the js file:
https://github.com/netlify/js-client/blob/6070f83a528eb4685c10764c1bd9716b80a07935/src/deploy/index.js

- What is the expected behavior?
The parameters should be named as they get used.

- Please mention your node.js, and operating system version.
OS X / node v10.15.0

createSiteBuild

- Do you want to request a feature or report a bug?
bug

- What is the current behavior?
Error: Missing required param site_id

- If the current behavior is a bug, please provide the steps to reproduce.
const build = await currentClient.createSiteBuild({ body: { site_id: deploy.site_id } })

- What is the expected behavior?
to create the build
- Please mention your node.js, and operating system version.
node v10.16.0 macOS catalina 10.15.2

Allow calling API endpoints not in OpenAPI yet

The Netlify OpenAPI specification is missing many endpoints and is often lagging behind. Also, we purposely don't add some endpoints there for features that have not been announced yet.

Because of this, we have refrained from using the js-client in many projects, and prefer to call the Netlify API directly (example). However, the js-client provides with a consistent way to request the Netlify API and parse its response, which we should re-use across projects.

Therefore, we should add a way to call API endpoints that are not in OpenAPI yet.

Uploading many files is slow

- Do you want to request a feature or report a bug?
Feature

- What is the current behavior?
Js-Client is very slow when you need to upload >10k pages. It doesn't take advantage of parallel uploading in a single thread (say 10 files in parallel) nor does it take advantage of multiple threads (child workers). I'm pretty confident deployment could be insanely faster with these.

See: netlify/cli#318
A good example implementation of parallel and multithread work is nextjs export: https://github.com/zeit/next.js/tree/canary/packages/next/export

BUG: Gatsby Build Issue just by Adding Netlify JS Client API

Yesterday after I updated my package set there is an error that occurs that causes the Gatsby Build to file.
After further investigation removing the NETLIFY js API seems to fix the issue.

The build error is as follows:
`failed Building static HTML for pages - 20.250s
error Building static HTML failed

131 |
132 | const path = require('path').join(__dirname, 'elf_cam_bg.wasm');

133 | const bytes = require('fs').readFileSync(path);
| ^
134 |
135 | const wasmModule = new WebAssembly.Module(bytes);
136 | const wasmInstance = new WebAssembly.Instance(wasmModule, imports);

WebpackError: ENOENT: no such file or directory, open '/elf_cam_bg.wasm'`

Screenshot 2020-12-13 at 01 34 09

Tested on Netlify with Node 14.15.1
and also Locally on Mac OS with node 15.1.0 and 14.15.0

Improve API pagination support

Currently pagination is dictated via the open-api spec support and, for the list endpoints that support it, users will need to rely on the per_page and page params to iteratively fetch new data. The fact that we're not exposing the response headers also means users will have no way to know when further data is available or not.

We should figure a user friendly API mechanism to deal with this - e.g. #39 (comment) 👍

bug: createDnsRecord throws "undefined method `end_with?' for nil:NilClass"

- Do you want to request a feature or report a bug?
This is a bug report

- What is the current behavior?
Trying to create DNS records using

const NetlifyAPI = require("netlify");
const client = new NetlifyAPI("TOKE");
(async () => {
  const dnsZone = await client.getDNSForSite({
    site_id: "SITE_ID",
  });
  await client.createDnsRecord({
    zone_id: dnsZone[0].id,
    type: record.type,
    hostname: record.name,
    value: record.value,
  });
})();

throws the following error

ERROR: JSONHTTPError: Internal Server Error
    at parseResponse ([..]/node_modules/netlify/src/methods/response.js:12:11)
    at processTicksAndRejections (internal/process/task_queues.js:94:5)
    at async callMethod ([..]/node_modules/netlify/src/methods/index.js:38:26)
    at async [..]/netlify-create-dns.js:17:7 {
  name: 'JSONHTTPError',
  status: 500,
  json: { error: "undefined method `end_with?' for nil:NilClass" }
}

It's already been brought up in the community

- If the current behavior is a bug, please provide the steps to reproduce.
Using the code from above using a valid API token and correct site id found in https://app.netlify.com/sites/SITE_NAME/settings/general -> Site Information: APP ID

- What is the expected behavior?
Creation of DNS records.

- Please mention your node.js, and operating system version.
NodeJS v12.14.1, macOS 10.14.6

How to use the UMD version in a webpack environment?

Hello there.

I'm trying to import the UMD version in a Vue project that is based on webpack respectively https://laravel.com/docs/6.x/mix. It ends up in the following error message:

netlify:15357 Uncaught Error: Module parse failed: Unexpected token (11:6)
You may need an appropriate loader to handle this file type.
|   if (isBinaryBody(parameters)) {
|     return {
|       ...opts,
|       body: bodyA,
|       headers: { 'Content-Type': 'application/octet-stream', ...opts.headers }

I'm trying to use it as follows:

import { NetlifyAPI } from "netlify";
const client = new NetlifyAPI(
  "[api_key]"
);

Did anybody have success with the webpack/UMD combination?

Dependency Dashboard

This issue lists Renovate updates and detected dependencies. Read the Dependency Dashboard docs to learn more.

Ignored or Blocked

These are blocked by an existing closed PR and will not be recreated unless you click a checkbox below.

Detected dependencies

github-actions
.github/workflows/fossa.yml
  • actions/checkout v3
.github/workflows/labeler.yml
  • netlify/pr-labeler-action v1.1.0
.github/workflows/release-please.yml
  • navikt/github-app-token-generator a9cd374e271b8aef573b8c16ac46c44fb89b02db
  • GoogleCloudPlatform/release-please-action v3
  • actions/checkout v3
  • actions/setup-node v3
.github/workflows/workflow.yml
  • actions/checkout v3
  • actions/setup-node v3
  • codecov/codecov-action v3
npm
package.json
  • @netlify/open-api ^2.12.0
  • lodash.camelcase ^4.3.0
  • micro-api-client ^3.3.0
  • node-fetch ^3.0.0
  • omit.js ^2.0.2
  • p-wait-for ^4.0.0
  • qs ^6.9.6
  • @netlify/eslint-config-node ^7.0.0
  • ava ^4.0.0
  • c8 ^7.11.0
  • from2-string ^1.1.0
  • husky ^8.0.0
  • nock ^13.0.0
  • npm-run-all ^4.1.5
  • uuid ^8.3.2
  • node ^12.20.0 || ^14.14.0 || >=16.0.0

  • Check this box to trigger a request for Renovate to run again on this repository

Clarity on disposition towards semver and breaking changes

I recently realized I was running a version of this JS client back at v2. The most recent is v6. This immediately struck terror in my heart that I'd have to consider parsing the release notes from 3 to 4 to 5 to 6 to see what changed.

After looking at the CHANGELOG, I saw nothing mentioning breaking changes. Still, I had gone from v2 to v6 and the upgrade seemed scary. After searching the issues, I still saw nothing about breaking changes and decided to just go for it. Upgrading v2 to v6 seemed to work just fine.

It'd be nice if there was some clarity stated on the project about what major version changes for this tool mean, if anything, to the consumer of this library. Even there was something at the top of the CHANGELOG, for example, that said "Don't worry, any major version bump in this tool means nothing to you. Only worry about the Netlify API itself changing (which would likely mean a new tool anyway). Carry on." Or something like that.

I just have no idea what bumping from v2 to v6 meant for me as someone who has scripts which use this tool. Apparently it meant nothing.

How do you handle error responses?

Hi

How do you handle error responses with netlify node-client.

For instance, if I update a site with a name that is already taken, how do you get the error response from update call.

I tried
`client.site(req.params.b).then(function(site) {

	site.update({name: req.params.c}).then(function(site) {
	res.success(site);
	}, function(error){
	res.error(error);	
	});
});`

But it does not work.

Any help please

Ship a new release?

It'd would be nice to get #6 out into a release so npm stops telling me I'm using a deprecated version of graceful-fs.

Lack of support for X-RateLimit during deployment

Hi,

I have discovered an issue with your node client - your API has limit of 200 requests per minute, but it is impossible to handle it during deploying the website using your client.

I have temporary fixed this issue by limiting parallels connections from 20 to 2: https://github.com/netlify/node-client/blob/master/lib/deploy.js#L56

but in fact the library should handle the X-Rate* headers and detect API limitations during deploying a website automatically.

Browser support?

The Readme states that the library supports both Node.js and the browser. Looking for the browser code I only found

throw new Error('Deploys not supported in the browser')

Is browser support planned for the future or is the readme wrong?

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

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

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

Feature: Support specifying commit sha/URL when creating/updating a deploy

Related to netlify/cli#1122

- Do you want to request a feature or report a bug?

Feature

- What is the current behaviour?

Manual deploys shown in the Netlify UI are not linked to any commit.

- What is the expected behaviour?

An option should be provider to tag a deploy with a commit sha or URL so one could click the deploy in the Netlify UI and be redirected to the relevant commit in the repo.

- Possible workaround

Use the message argument, but that doesn't create a link in the UI

Add Typescript types to package or @types/netlify

- Do you want to request a feature or report a bug?

Feature I guess?

- What is the current behavior?

There are no Typescript types in the repo or on @types/netlify for this package

- What is the expected behavior?

There are types for the package 😄

- Please mention your node.js, and operating system version.

n/a

Return the whole response object from the methods

The current js-client API implementation is restrictive in the sense that it only exposes the response body and an error if that's the case. Coming from discussions in #285 #39 #156 I feel like it would make sense and there's enough room to add some sort of support for our methods to return the whole response object.

I realise this could easily be a breaking change, but maybe we could come up with a strategy where that wouldn't be the case?

Do not expose API token

The API token is exposed as apiClient.accessToken. This is a security concern when the client is passed between different trusted domains.

For example, Build plugins perform logic on behalf of the user. They receive an instance of the API client with the user's access token. However they should not see the API token.

Feature: Decrease bundle size by including only specified methods

I am using the js-client with Next.js and the netlifyAPI class increases my bundle size by approx. 20 KB, although I am using just a few methods. This is too much for a typical SPA and should be reduced. I have not found a way to include only the methods I actually need, which would substantially reduce the bundle size.

I think the problem is that all methods specified are exported:

module.exports.methods = getOperations()

const { paths } = require('@netlify/open-api')

Feature request: Implement a configuration option which allows only to include pre-specified methods with the aim to substantially reduce bundle size.

Create new site (and delete existing one)

We are trying to create new site on netlify and deploy files as a one command. While deploy command is available in the client, create site functionality is missing, as well as removing site. Considering these functions are available in C# client, it looks natural to have them here.

Retry request on ETIMEDOUT

- Do you want to request a feature or report a bug?
feature? enhancement?

- What is the current behavior?
We have an enterprise customer who's hitting errors like this (redacted for privacy) a few times every day, impacting 5-10% of their daily builds:

FetchError: request to https://api.netlify.com/api/v1/sites/xxxxxxx-xxxxxxx failed, reason:
    connect ETIMEDOUT 3x.xxx.xx.xxx:443
    Code: ETIMEDOUT

@kitop investigated and found that the error was coming from node-fetch. He says:

Seems like that's happening because one of the requests from the client fails to connect to the API servers when polling for the deploy being ready. Some related issue: node-fetch/node-fetch#817
If I turn on my wifi and try to run a command from CLI it shows a similar error

Request
Can we retry when there's a timeout like this? It looks like we currently retry when hitting a rate limit but not when there's a network issue:

const makeRequestOrRetry = async function({ url, method, NetlifyApi, requestParams, opts }) {
for (let index = 0; index <= MAX_RETRY; index++) {
const optsA = getOpts(method, NetlifyApi, requestParams, opts)
const response = await makeRequest(url, optsA)
if (shouldRetry(response, index)) {
await waitForRetry(response)
} else {
return response
}
}
}
const makeRequest = async function(url, opts) {
try {
return await fetch(url, opts)
} catch (error) {
throw getFetchError(error, url, opts)
}
}

Additional context

Support Netlify Large Media

- Do you want to request a feature or report a bug?

There are a couple of things we need to add to support Netlify Large Media in the CLI.

- What is the current behavior?

We don't support Netlify LM

- What is the expected behavior?

When a site has LM enabled, we need to read information from LFS pointer files to add them to the deploy requests. This logic is already implemented in the Go client:

https://github.com/netlify/open-api/blob/master/go/porcelain/deploy.go#L512-L532

The original file size needs to be sent as a parameter when we upload a file:

https://github.com/netlify/open-api/blob/master/go/porcelain/deploy.go#L424-L431

There is a caveat to keep in mind in this implementation:

netlify/open-api@2af0664

Maybe @keiko713 can say more about that special hashed key.

bug: GET `/sites` does not retrieve all sites, specifically sites in shared teams

- Do you want to request a feature or report a bug?
This is a bug report.

- If the current behavior is a bug, please provide the steps to reproduce.
I currently have my own personal Netlify team and I also belong to a Netlify team that has several coworkers. The latter Netlify team has >100 sites.

However, when I make the following request - GET https://api.netlify.com/api/v1/sites?access_token=<ACCESS_TOKEN> - I only retrieve a subset of sites that I have access to (specifically 52 sites). The response does not contain a next page in the link response header, even though I should be able to see >100 sites.

- What is the expected behavior?
The expected behavior is to list out all sites that I can see.

- Please mention your node.js, and operating system version.
Node.js v12.16.1, macOS Mojave 10.14.6

Action Required: Fix Renovate Configuration

There is an error with this repository's Renovate configuration that needs to be fixed. As a precaution, Renovate will stop PRs until it is resolved.

Error type: undefined. Note: this is a nested preset so please contact the preset author if you are unable to fix it yourself.

Feature request: Better handle API errors

- What is the current behavior?

Currently if Netlify's API returns an HTTP error (4xx/5xx) status code during an action, we show the error but it's not usually very actionable:

$ netlify deploy --dir dist/ -a $NETLIFY_TOKEN -s $NETLIFY_SITE_ID --prod
Deploy path: [redacted]
Deploying to live site URL...
- Hashing files...
✔ Finished hashing 3222 files
- CDN diffing files...
 ›   Warning: TextHTTPError: 502
 ›   Warning: 
 ›   TextHTTPError: Bad Gateway
 ›
TextHTTPError: Bad Gateway
    at NetlifyAPI.createSiteDeploy ([redacted])
    at <anonymous>
error Command failed with exit code 2.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.

We saw the same thing for HTTP 429, though I think the root cause here has since been fixed:

$ netlify deploy --dir dist/ -a $NETLIFY_TOKEN -s $NETLIFY_SITE_ID_STAGING
Deploy path: [redacted]
Deploying to draft URL...
- Hashing files...
 Finished hashing 3181 files
- CDN diffing files...
 CDN requesting 2606 files
- Uploading 2606 files
› Warning: JSONHTTPError: Access Denied: bad return from the origin: 429 401
› Warning: 
› {
› "name": "JSONHTTPError",
› "status": 401,
› "json": {
› "code": 401,
› "message": "Access Denied: bad return from the origin: 429"
› }
› }
›

- If the current behavior is a bug, please provide the steps to reproduce.

@biilmann and @bcomnes were discussing this in this internal thread: https://netlify.slack.com/archives/CBC2U9MMG/p1551719842008700

- What is the expected behavior?

Errors have some obvious & actionable next steps, e.g. display a message like "wait 5 minutes and try again?", or "please contact support with information X/Y/Z for help" or better yet just magically retrying under the covers :)

This was observed with CLI version 2.8.1

"branch" in .deploy({ branch }) accepts upper case letters and symbols, but deployment is "Not Found"

- What is the current behavior?

When I deployed with branch: which includes upper cases or symbols, deployment is done successfully. But, deployed URL, .deploy.deploy_ssl_ur tells me "Not Found".

const NetlifyAPI = require('netlify');

const token = process.env.NETLIFY_AUTH_TOKEN;
const siteId = process.env.NETLIFY_SITE_ID;

const client = new NetlifyAPI(token);

(async () => {
  const deploy = await client.deploy(siteId, './public', {
    draft: true,
    branch: 'UPPERCASE', // https://uppercase--nwtgck-netlify-test.netlify.app/
    // branch: 'slash/hoge', // https://slash-hoge--nwtgck-netlify-test.netlify.app/
    // branch: 'under_score', // https://under-score--nwtgck-netlify-test.netlify.app/

  });
  console.log('URL: ', deploy.deploy.deploy_ssl_url);
})();

- What is the expected behavior?

The internal API or this "js-client" converts "branch" property properly.

my workaround

branch = branch.replace(/[^a-zA-Z\d]/g, '-').toLowerCase()

related: nwtgck/actions-netlify#243

Functions do not deploy when following README

- What is the current behavior?
Functions do not deploy to Netlify when a functions directory is specified as functionsDir in opts object of client.deploy(), as described in the API Flow methods section of README.md, and instead are silently skipped. Functions do deploy when a function directory is specified as fnDir, matching implementation in src/deploy/index.js.

- If the current behavior is a bug, please provide the steps to reproduce.

  1. Attempt to deploy functions using client.deploy('SOME_SITE_ID', './dist', { functionsDir: './functions' } as in README.md. Functions do not deploy.
  2. Change to client.deploy('SOME_SITE_ID', './dist', { fnDir: './functions' }. Functions deploy correctly.

- What is the expected behavior?
Opts for client.deploy match in README and functionality.

- Please mention your node.js, and operating system version.
Node v8.11.0
Ubuntu 19.04/disco

Deploy step fails on random steps due to network errors

From netlify/cli#10 (comment)

I have this problem when I do $ netlify deploy --prod on the first time. It show something like...

Deploying to live site URL...
√ Finished hashing 7 files
√ CDN requesting 7 files
√ Finished uploading 7 assets
| Waiting for deploy to go live... »   Warning:
 »   {
 »      "message": "request to
 »   https://api.netlify.com/api/v1/sites/04c14fe2-e27a-4ed4-b10c-f81a2bfbd27c/deplo
 »   ys/5c6ed79fef12041c97a94db0 failed, reason: read ECONNRESET",
 »      "type": "system",
 »      "errno": "ECONNRESET",
 »      "code": "ECONNRESET",
 »      "name": "FetchError",

but, after few seconds I run the same command again it then work fine.
and I got

Deploying to live site URL...
√ Finished hashing 7 files
√ CDN requesting 0 files
√ Finished uploading 0 assets
√ Deploy is live!

Not sure if it help to point out to the cause of the problem...

feat: parse error data

Currently, unsuccessful requests .reject the promise with a strange { client, data, meta } object.

  1. Why is client in there?
  2. Why is data an unparsed string of this kind:
{ data: '{"code":429,"message":"API Deploy rate limit surpassed for application"}' }
{ data: '{"errors":{"subdomain":["must be unique"]}}' }

Maybe it would be better to reject with an Error object containing the message part and the other things like meta, code, and errors tacked on as properties?

Build settings environment variables are not getting updated

Hi, I am trying createSite() or updateSite() of your js API.
I can create (partially) new site with createSite. The name of the new site is correct but no other arguments are taken into account .
I am actually just trying to populate environment variables in build settings with

.updateSite({
    site_id,
    build_settings: {env}
  });
}

But nothing gets updated

Do not export `methods`

I think methods should remain an internal representation of the OpenAPI specification. Exporting it makes it harder to change that internal representation without introducing breaking changes.

Users that need to know which methods we expose should either:

  • use Object.keys(NetlifyAPI.prototype)
  • require @netlify/open-api

There are currently no public repositories that use that exported variable on GitHub, except our own repositories. So we would need to modify it in our repositories, then make a major release.

Type definition file for typescript support.

**- Do you want to request a feature or report a bug?**Feature

- What is the current behavior?
we only have js client
- If the current behavior is a bug, please provide the steps to reproduce.

- What is the expected behavior?

- Please mention your node.js, and operating system version.

Link to Github

Is it possible to create a site and link it to a Github/Gitlab/Bitbucket repository automatically?

client.createSite({
  name: 'my_name',
  domain: 'my_domain',
  repo: 'my_repo'
});

createSite not using arguments

I made a fix to the README about a related item which was just accepted:
#101

But now I realise it's not listening to any of the parameters I pass in. For example if I run:

  const site = await client.createSite({
    name: `my-awesome-site`,
    repo: {
      provider: "github",
      ...
    },
  });

It doesn't name the site according to the name I provided (nor does any of the GitHub linking work)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.