profile
viewpoint
Jessica Parsons verythorough @netlify SF Bay Area

netlify/gotrue 1153

An SWT based API for managing users and issuing SWT tokens

netlify/gocommerce 963

A headless e-commerce for JAMstack sites

freeCodeCamp/2018-jamstack-hackathon 25

IN PERSON freeCodeCamp JAMstack Hackathon on November 3 - 4 at GitHub

freeCodeCamp/2018-online-jamstack-hackathon 20

freeCodeCamp JAMstack Online Hackathon November 3 - 4

netlify/netlify-auth-demo 18

Demo for integrating GitHub OAuth with a Netlify site

verythorough/bigurl 5

A bookmarklet for projecting the current url in large type for people viewing your screen from a distance

jkarnowski/gdi-featured-html-css-intro 1

Slides and handouts for GDI Intro to HTML course

verythorough/destina 1

Shared travel planning maps

push eventverythorough/where-in-the-world

Jessica Parsons

commit sha e068890e67df2eddaf8261f295348b08948324a9

Move _functions folder

view details

push time in 4 days

fork verythorough/where-in-the-world

[React] [Hasura] Real-time, interactive, image-based game show application built on the JAMstack; FCC/Netlify 2018 Hackathon Grand Prize Recipient

https://witworld.live/

fork in 4 days

pull request commentnetlify/plugins

Add Dotenv plugin

@krotovic if you do decide to troubleshoot running your plugin locally, I think it could be cool if you added a default mode that only accesses .env in local builds, then require a setting in inputs to allow it to run on Netlify as well. (h/t to @ehmicky for this idea!)

It adds a little complexity, and people wanting to use your plugin the way you do (in Netlify CI) would have to add the inputs field to their netlify.toml file, but the tradeoff is that the plugin would get a bigger audience by being in the UI.

krotovic

comment created time in 10 days

startedddbeck/readme-checklist

started time in 15 days

push eventverythorough/verythorough.github.io

Jessica Parsons

commit sha c725bb1c18fb0b61e9fcce7219099ce93230363e

Add a new sentence fragment

view details

push time in a month

push eventverythorough/verythorough.github.io

Jessica Parsons

commit sha 23f69520e4d4200fe47aa6774a0328b033868c75

Add period.

view details

push time in a month

issue commentnetlify/cli

Bug: deploy command regression

Based on the clues from @cadbox1's comment, I suspect the repro attempts might not be working because the sites they're creating differ from @DavidWells's original failing sites in one of two ways:

  • The failing sites might have a base directory set in the UI.
  • The failing sites might have been created before October 2019, when the introduction of monorepo support changed how base and publish directories are handled.

Neither of those things would be true of the new sites being created for repro testing.

DavidWells

comment created time in a month

issue commentnetlify/build-image

Yarn install runs even when a node_modules cache is found

Marking this as type: bug because it predates Build Plugins work.

jlengstorf

comment created time in a month

issue commentnetlify/build-image

Once the Netlify Build beta goes GA, remove `zip-it-and-ship-it` code

@ehmicky @Benaiah I'm moving this to the fast-follow milestone. Can you help assign it to the appropriate person?

ehmicky

comment created time in a month

pull request commentnetlify/build

Add Redirects utility

@ehmicky @RaeesBhatti What's the status on this PR?

RaeesBhatti

comment created time in a month

pull request commentnetlify/build

Add headers utility

@ehmicky @RaeesBhatti What's the status on this PR?

RaeesBhatti

comment created time in a month

issue commentnetlify/build

Cross-plugin communication using `process.env`

@ehmicky What's the current status on this issue? is it related to #611 at all?

ehmicky

comment created time in a month

issue commentnetlify/build

Plugin Output Proposal

@ehmicky What's the current status on this issue?

DavidWells

comment created time in a month

issue commentnetlify/plugins

Remove plugins with required inputs

@erezrokah Does the Ghost plugin not work when the required env vars are set?

erezrokah

comment created time in a month

issue commentnetlify/build

Improve support for environment variable as inputs

That provides a pretty clean fallback - I like that! Since it's a common use case, it would be nice to have something built-in like this rather than requiring authors to implement their own fallback behaviors.

ehmicky

comment created time in a month

issue closednetlify/build

Remove backward compatibility on Thursday 21st May

The following properties have been previously renamed. We have been maintaining backward compatibility, but this should be removed before GA.

Plugin event handler arguments:

  • pluginConfig -> inputs (#1338)
  • config -> inputs (#1338)
  • constants.BUILD_DIR -> constants.PUBLISH_DIR
  • utils.build.fail() -> utils.build.failBuild() (#1340)
  • utils.build.cancel() -> utils.build.cancelBuild() (#1340)

Plugin properties:

  • config -> manifest.yml inputs (#1341)
  • inputs -> manifest.yml inputs (#1341)
  • name -> name in manifest.yml (#1341)

manifest.yml optional -> required (#1343)

Plugin event handlers (#1339):

  • preBuild -> onPreBuild (same for other events)
  • onprebuild -> onPreBuild (same for other events)
  • onInit -> onPreBuild
  • on[Pre|Post]GetCache -> onPreBuild
  • on[Pre|Post]Install -> onPreBuild
  • on[Pre|Post]FunctionsBuild -> onPostBuild
  • on[Pre|Post]FunctionsPackage -> onPostBuild
  • onPreDeploy -> onPostBuild
  • on[Pre|Post]SaveCache -> onPostBuild
  • finally -> onEnd

netlify.toml properties:

  • build.lifecycle -> build.command (#1345)
  • plugins[*].type -> plugins[*].package (#1346)
  • plugins[*].config -> plugins[*].inputs (#1347)
  • plugins[*].id -> removed (#1349)
  • plugins[*].enabled -> removed (#1348)

netlify.yaml|yml|json (#1344)

@netlify/plugin-functions-install-core (#1351) and @netlify/plugin-local-install-core (#1350) should be opt-in not opt-out.

closed time in a month

ehmicky

issue commentnetlify/zip-it-and-ship-it

Error while bundling Netlify Functions in local builds

If this is fixed, shouldn't it be closed?

ehmicky

comment created time in a month

delete branch verythorough/list

delete branch : edit-netlify-entry

delete time in a month

issue commentnetlify/build

Fix merging of UI-installed plugins and `netlify.toml` plugins

In other configuration options that can be set via UI as well as netlify.toml, the netlify.toml settings always override anything in the UI. I suspect we could do that here, as well: if a plugin with the same package is listed in the site's netlify.toml file as in the UI, all UI configuration of the plugin would ignored.

(Down the line, we could get fancy about handling context-specific plugin settings in the netlify.toml file.)

ehmicky

comment created time in a month

PR opened netlify/plugins

Deactivate plugins requiring inputs

Deactivating the following plugins:

  • netlify-plugin-brand-guardian (@tzmanics )
  • netlify-plugin-rss (@sw-yx )
  • netlify-plugin-add-instagram (@philhawksworth )

These plugins require inputs to be set, but this can't be done in the Netlify UI. When possible, configure your plugin to work with a config-free default, or if some config must be required, allow them to be set via env vars. (More details in the new plugin author guidelines.)

+6 -3

0 comment

1 changed file

pr created time in 2 months

create barnchnetlify/plugins

branch : jp/requiredInputsDeactivation

created branch time in 2 months

delete branch netlify/plugins

delete branch : jp/docs/updatesForContributors

delete time in 2 months

push eventnetlify/plugins

Jessica Parsons

commit sha 72402b751e4d9a8c1e3ced1aed97b4cee6700323

Remove generated plugin list to ease contributions

view details

Jessica Parsons

commit sha a08c9b44a695606757a62655d6440dabcdeb5e79

Add contributing details and author guidelines

view details

Jessica Parsons

commit sha d8f31e51066e75b554f1e69ae446b8623c10725a

Add a license and code of conduct.

view details

Jessica Parsons

commit sha c5c94ecbbbe2f41b802234f0b9e67b41b3a11882

Move contributor guide and guidelines to /docs

view details

Jessica Parsons

commit sha 5454fae089896585562c42eba3c385f0bbd6e104

Add issue & PR templates

view details

Jessica Parsons

commit sha 2b96755a79dd6bb71d4a1bed84baac8315370e71

Update contributor guide and readme

view details

Jessica Parsons

commit sha ab68f0fc14ab0c651394c904d3376e8d0ddb6c47

Add test plan to template

view details

Jessica Parsons

commit sha 00f462a895d204b656e3d180ff6b3ee8d156c359

Update based on review

view details

Jessica Parsons

commit sha e86de8d55e3417c087bc6570e45d5539216619a9

Merge pull request #44 from netlify/jp/docs/updatesForContributors

view details

push time in 2 months

PR merged netlify/plugins

Reviewers
Docs: Updates for contributors type: feature

Summary This PR makes several changes to improve the contributor experience:

  • Adds plugin author guidelines, extended contributor guide, and PR & issue templates.
  • Adds a license (MIT) and a code of conduct (Contributor Covenant 2.0).
  • Removes the generated list of plugins from the README. This simplifies plugin additions, removing the need to clone and run the generation script locally. Instead, the README links to the plugins directory on Netlify.

Test plan

  • Please double-check links.
  • Check for typos or other errors in writing.
  • Comment on any areas you think should be handled differently.

Additional context Closes #20 Closes #29

+266 -129

1 comment

9 changed files

verythorough

pr closed time in 2 months

issue closednetlify/plugins

Document/communicate to plugin authors the new release process

We will soon lock plugin versions (#27), which means new ones will need to go through a PR and code review process.

We should document this in netlify/build and netlify/plugins README.md.

Any thoughts?

@verythorough @mheffner @erquhart

closed time in 2 months

ehmicky

issue closednetlify/plugins

Add guidelines for plugin authors seeking inclusion in the list

@ehmicky has summarized common plugin issues in a separate issue comment. We can convert this information into a checklist of items needed before submitting a PR to add a plugin to the list.

We could add the content to the README (or contributor guide?), and could also benefit from putting the checklist into a PR template.

Auto-linting would be great, too, but until then, guidance works. :)

closed time in 2 months

verythorough

pull request commentnetlify/plugins

Docs: Updates for contributors

Made a few changes based on review. Ready for re-review!

verythorough

comment created time in 2 months

push eventnetlify/plugins

Jessica Parsons

commit sha 00f462a895d204b656e3d180ff6b3ee8d156c359

Update based on review

view details

push time in 2 months

Pull request review commentnetlify/plugins

Docs: Updates for contributors

+# Plugin Author Guidelines++Netlify plugins listed in the plugins.json file of this repository can be installed directly within the Netlify UI from the plugins directory. To help ensure a consistent user experience, we've prepared the following guidelines for authors submitting plugins to the directory.++Before submitting a plugin for the plugins directory, please read and follow the guidelines below.++## Provide a zero-config default.++Plugins with required `inputs` cannot be installed via the Netlify UI. Wherever possible, a plugin should include default options that allow the plugin to run without configuration. In cases where a plugin requires a unique value (such as an API key for a third-party service), configure the plugin to accept this value from a [build environment variable](https://docs.netlify.com/configure-builds/environment-variables). For more complex or customized configuration, users can install the plugin via the `netlify.toml` configuration file.++## Provide a README.++Every plugin in the Netlify plugins directory includes a link to the plugin README. This file should include:+- A description of what the plugin does and why that might be useful.+- Any required environment variables.+- Instructions for installing via `netlify.toml` configuration file, including any optional `inputs`.+- Ideally, a link to a demo site with [public deploy logs](https://docs.netlify.com/configure-builds/get-started/#basic-build-settings) and a [Deploy to Netlify button](https://docs.netlify.com/site-deploys/create-deploys/#deploy-to-netlify-button), so users can find out how the plugin works before installing.++## Follow best practices for plugin code and metadata.++Consistency across plugins makes plugins easier to find, easier to debug, and easier to review for inclusion in the Netlify plugins directory. This [issue comment](https://github.com/netlify/build/issues/1068#issuecomment-605276244) describes common pitfalls to avoid.

I'm planning to add the contents of the comment to the main docs, and will update the link when available.

Regarding the portion about deprecate methods, I was wondering if we should keep a separate running list of which methods which have been deprecated or removed, with dates of deprecation and/or removal. I think this might make sense in the build repo. What do you think?

verythorough

comment created time in 2 months

Pull request review commentnetlify/plugins

Docs: Updates for contributors

+# Plugin Author Guidelines++Netlify plugins listed in the plugins.json file of this repository can be installed directly within the Netlify UI from the plugins directory. To help ensure a consistent user experience, we've prepared the following guidelines for authors submitting plugins to the directory.++Before submitting a plugin for the plugins directory, please read and follow the guidelines below.++## Provide a zero-config default.++Plugins with required `inputs` cannot be installed via the Netlify UI. Wherever possible, a plugin should include default options that allow the plugin to run without configuration. In cases where a plugin requires a unique value (such as an API key for a third-party service), configure the plugin to accept this value from a [build environment variable](https://docs.netlify.com/configure-builds/environment-variables). For more complex or customized configuration, users can install the plugin via the `netlify.toml` configuration file.++## Provide a README.++Every plugin in the Netlify plugins directory includes a link to the plugin README. This file should include:+- A description of what the plugin does and why that might be useful.+- Any required environment variables.

Hm, good point. I want the required env vars to be separate, though, so it's clear they're needed for all installations. I can add the optional ones to the next point.

verythorough

comment created time in 2 months

Pull request review commentnetlify/plugins

Docs: Updates for contributors

+# Plugin Author Guidelines++Netlify plugins listed in the plugins.json file of this repository can be installed directly within the Netlify UI from the plugins directory. To help ensure a consistent user experience, we've prepared the following guidelines for authors submitting plugins to the directory.++Before submitting a plugin for the plugins directory, please read and follow the guidelines below.++## Provide a zero-config default.++Plugins with required `inputs` cannot be installed via the Netlify UI. Wherever possible, a plugin should include default options that allow the plugin to run without configuration. In cases where a plugin requires a unique value (such as an API key for a third-party service), configure the plugin to accept this value from a [build environment variable](https://docs.netlify.com/configure-builds/environment-variables). For more complex or customized configuration, users can install the plugin via the `netlify.toml` configuration file.++## Provide a README.++Every plugin in the Netlify plugins directory includes a link to the plugin README. This file should include:+- A description of what the plugin does and why that might be useful.+- Any required environment variables.+- Instructions for installing via `netlify.toml` configuration file, including any optional `inputs`.

I left the link out for this iteration because the link is about to change. I suppose I could still tell people to link to the installation docs without actually providing the link yet. 🤔

verythorough

comment created time in 2 months

push eventnetlify/plugins

Jessica Parsons

commit sha ab68f0fc14ab0c651394c904d3376e8d0ddb6c47

Add test plan to template

view details

push time in 2 months

issue closednetlify/plugins

How to account for plugins "removed" from the list

The list of plugins in plugins.json populates the list of plugins in the Netlify UI. Sometimes, plugins will have to be removed, for example, if the plugin stops working, stops meeting the guidelines (#20), or is unpublished from npm.

We could just remove the plugin from the json list, but there are instances where we might still want information about the plugin available - for example, to display currently installed plugins in the UI.

One way to do this would be to add an "active": false field to an inactive plugin. (I'd say "inactive": true, but I hesitate because double negatives can be tricky.) When a plugin has that field, I think we might also want to:

  • Change the name to Some Plugin Name (inactive), so another author might be able to add a new plugin called Some Plugin Name.
  • Remove the repo URL, or account for the fact that it may no longer exist or be useful.
  • Change or remove other fields?

Thoughts? cc @erquhart @nasivuela @charliegerard @ehmicky

closed time in 2 months

verythorough

push eventnetlify/plugins

Jessica Parsons

commit sha 5454fae089896585562c42eba3c385f0bbd6e104

Add issue & PR templates

view details

Jessica Parsons

commit sha 2b96755a79dd6bb71d4a1bed84baac8315370e71

Update contributor guide and readme

view details

push time in 2 months

push eventnetlify/plugins

Jessica Parsons

commit sha d8f31e51066e75b554f1e69ae446b8623c10725a

Add a license and code of conduct.

view details

Jessica Parsons

commit sha c5c94ecbbbe2f41b802234f0b9e67b41b3a11882

Move contributor guide and guidelines to /docs

view details

push time in 2 months

PR opened netlify/plugins

Docs: Updates for contributors

Opening a draft; more work to come.

+52 -131

0 comment

3 changed files

pr created time in 2 months

create barnchnetlify/plugins

branch : jp/docs/updatesForContributors

created branch time in 2 months

delete branch netlify/build

delete branch : docs/build-cli

delete time in 2 months

push eventnetlify/build

ehmicky

commit sha 64078ab0fdc1d64a337bd93b39dc8f4adaed6eb9

Add more documentation about the `netlify build` CLI command (#1358)

view details

push time in 2 months

PR merged netlify/build

Add more documentation about the `netlify build` CLI command documentation type: feature

Fixes #1232.

This adds more documentation about the netlify build CLI command.

+3 -0

0 comment

1 changed file

ehmicky

pr closed time in 2 months

issue closednetlify/build

Document `netlify build` CLI

We should document the netlify build CLI commands and its available flags in the README.md.

closed time in 2 months

ehmicky

delete branch netlify/build

delete branch : docs/utils

delete time in 2 months

push eventnetlify/build

ehmicky

commit sha 475b7c676b036343e4a0922163f45bdfc6ae7c7f

Add documentation about utilities (#1357)

view details

push time in 2 months

PR merged netlify/build

Add documentation about utilities documentation type: feature

Fixes #1231.

This adds documentation about utils in the README.md.

+12 -0

0 comment

1 changed file

ehmicky

pr closed time in 2 months

issue closednetlify/build

Better documentation of `utils`

We should document (or link to the documentation) the officially supported utils in the README.

closed time in 2 months

ehmicky

delete branch netlify/build

delete branch : docs/constants

delete time in 2 months

push eventnetlify/build

ehmicky

commit sha 2629066c1a554e40452185a3f75f3c7319257499

Improve documentation of constants (#1330)

view details

push time in 2 months

PR merged netlify/build

Improve documentation of constants documentation type: feature

I have seen several bugs in plugins related to not taking into account that some constants:

  • might be undefined
  • might be defined but pointing to a directory that has not been created yet

More background at #1331

This PR tries to improve the documentation there.

+6 -4

0 comment

1 changed file

ehmicky

pr closed time in 2 months

delete branch netlify/build

delete branch : docs/local-plugin

delete time in 2 months

delete branch netlify/build

delete branch : docs/status-utils

delete time in 2 months

push eventnetlify/build

ehmicky

commit sha fede7cb0315067fd9b9cc1b2e518708e04744c5c

Improve documentation of local plugins (#1329)

view details

push time in 2 months

PR merged netlify/build

Improve documentation of local plugins documentation type: feature

The following:

[[plugins]]
package = "hello/world"

Could mean two things:

  • local path ./hello/world
  • GitHub repository github.com/hello/world. This is a recognized syntax by npm install.

To avoid confusion, and following the same convention as Node.js require(), local plugin paths must start with either . or /.

[[plugins]]
package = "./hello/world"

Some users though might forget the leading ./ (example error in production). This PR improves the documentation.

+2 -0

0 comment

1 changed file

ehmicky

pr closed time in 2 months

push eventnetlify/build

ehmicky

commit sha 0e40669499260ee084d21fc616a2490423c7960e

Add documentation for `utils.status.show()` (#1261)

view details

push time in 2 months

PR merged netlify/build

Add documentation for `utils.status.show()` documentation type: feature

This adds documentation in the README.md about the new utils.status.show() (#1223).

This PR should only be merged once this utility is available in production. However it is ready for code review.

+39 -0

0 comment

1 changed file

ehmicky

pr closed time in 2 months

issue commentnetlify/build

Improve Error DX

I think as a discussion issue, it makes sense to close this now. If there are remaining smaller tasks within the comments that haven't been addressed, we should file new, focused issues for them.

DavidWells

comment created time in 2 months

issue commentnetlify/build

Clarify where settings are loaded from

Related issue: https://github.com/netlify/buildbot/issues/650

jlengstorf

comment created time in 2 months

issue commentnetlify/build

Remove backward compatibility on Thursday 21st May

@ehmicky All of these items have been printing deprecation messages in build logs, correct?

ehmicky

comment created time in 2 months

issue commentnetlify/build

Build plugins do not work on Node 6 (or earlier)

Sounds good to me!

ehmicky

comment created time in 2 months

issue commentnetlify/build

Build plugins do not work on Node 6 (or earlier)

Do we know how many site on Xenial are using Node 6? I suspect it's very few.

In any case, I appreciate that #1239 will (hopefully) keep Node 6 users' builds from breaking when we flip over to Netlify Build for all Xenial sites, because we don't want builds to break without user action.

On the other hand, installing a plugin definitely counts as a user action, so I'm good with a build-failing error, preferably one which bubbles up into the deploy summary. (If it could take advantage of the existing plugin error functionality, that would be ideal.)

ehmicky

comment created time in 2 months

issue openednetlify/plugins

How to account for plugins "removed" from the list

The list of plugins in plugins.json populates the list of plugins in the Netlify UI. Sometimes, plugins will have to be removed, for example, if the plugin stops working, stops meeting the guidelines (#20), or is unpublished from npm.

We could just remove the plugin from the json list, but there are instances where we might still want information about the plugin available - for example, to display currently installed plugins in the UI.

One way to do this would be to add an "active": false field to an inactive plugin. (I'd say "inactive": true, but I hesitate because double negatives can be tricky.) When a plugin has that field, I think we might also want to:

  • Change the name to Some Plugin Name (inactive), so another author might be able to add a new plugin called Some Plugin Name.
  • Remove the repo URL, or account for the fact that it may no longer exist or be useful.
  • Change or remove other fields?

Thoughts? cc @erquhart @nasivuela @charliegerard @ehmicky

created time in 2 months

issue commentnetlify/build

`onError` event not triggered with `utils.build.failPlugin()`

I wonder if this is a naming issue. Are there any other non-fatal errors that trigger onError, or is it only triggered when the build actually fails?

If the latter, it sounds like the hook should be called onFailure (which matches onSuccess), and it should not include plugin failures that don't fail the build. (And then perhaps we consider adding some sort of onPluginFailure and/or onError events.)

tzmanics

comment created time in 2 months

create barnchnetlify/netlify-test-plugins

branch : fail-build-and-fail-plugin

created branch time in 2 months

create barnchnetlify/netlify-test-plugins

branch : fail-plugin-only

created branch time in 2 months

delete branch netlify/netlify-test-plugins

delete branch : fail-plugin-only

delete time in 2 months

create barnchnetlify/netlify-test-plugins

branch : fail-plugin-only

created branch time in 2 months

create barnchverythorough/netlify-test-plugins

branch : master

created branch time in 2 months

created repositoryverythorough/netlify-test-plugins

created time in 2 months

Pull request review commentnetlify/build

Add documentation about asynchronous code

 module.exports = { } ``` +### Asynchronous code++Asynchronous code can be achieved by using `async` methods:++```js+// index.js++module.exports = {+  onPreBuild: async ({ utils }) => {+    try {+      await doSomethingAsync()+    } catch (error) {+      utils.build.failBuild('Failure message', { error })+    }+  },+}+```++Any thrown `Error` or rejected `Promise` that is not handled by [`utils.build`](#error-reporting) will be reported as+bugs.

Yes! I understand now. :)

ehmicky

comment created time in 2 months

pull request commentnetlify/open-api

Add plugin_runs to open-api

Oh, sorry I missed the question, @vbrown608 ! Nice find in the ReDocs docs. I like your approach as an intermediate step as we work on the long term solution @keiko713 is now organizing.

vbrown608

comment created time in 2 months

Pull request review commentnetlify/build

Add documentation about asynchronous code

 module.exports = { } ``` +### Asynchronous code++Asynchronous code can be achieved by using `async` methods:++```js+// index.js++module.exports = {+  onPreBuild: async ({ utils }) => {+    try {+      await doSomethingAsync()+    } catch (error) {+      utils.build.failBuild('Failure message', { error })+    }+  },+}+```++Any thrown `Error` or rejected `Promise` that is not handled by [`utils.build`](#error-reporting) will be reported as+bugs.++```js+// index.js++module.exports = {+  onPreBuild: async ({ utils }) => {+    // Any error thrown inside this function will be reported as a bug.+    await doSomethingAsync()+  },+}+```++Plugins end as soon as their methods end. Therefore you should `await` any asynchronous operation. The following+examples show invalid code and the way to fix it:++```js+// index.js+const { promisify } = require('util')++module.exports = {+  // This callback will not be awaited+  onPreBuild: ({ utils }) => {+    doSomethingAsync((error, response) => {+      console.log(response)+    })+  },++  // This callback will be awaited+  onPostBuild: async ({ utils }) => {+    const response = await promisify(doSomethingAsync)()+    console.log(response)+  },+}+```

Is this whole sample the invalid example? If so, I recommend making this super clear with an all-caps comment so people don't just copy-paste it without reading the intro text. 😛

ehmicky

comment created time in 2 months

Pull request review commentnetlify/build

Add documentation about asynchronous code

 module.exports = { } ``` +### Asynchronous code++Asynchronous code can be achieved by using `async` methods:++```js+// index.js++module.exports = {+  onPreBuild: async ({ utils }) => {+    try {+      await doSomethingAsync()+    } catch (error) {+      utils.build.failBuild('Failure message', { error })+    }+  },+}+```++Any thrown `Error` or rejected `Promise` that is not handled by [`utils.build`](#error-reporting) will be reported as+bugs.

What does it mean to report something as a bug in this context? You will file issues on their repos? 😉

ehmicky

comment created time in 2 months

Pull request review commentnetlify/build

Add documentation about asynchronous code

 module.exports = { } ``` +### Asynchronous code++Asynchronous code can be achieved by using `async` methods:++```js+// index.js++module.exports = {+  onPreBuild: async ({ utils }) => {+    try {+      await doSomethingAsync()+    } catch (error) {+      utils.build.failBuild('Failure message', { error })+    }+  },+}+```++Any thrown `Error` or rejected `Promise` that is not handled by [`utils.build`](#error-reporting) will be reported as+bugs.++```js+// index.js++module.exports = {+  onPreBuild: async ({ utils }) => {+    // Any error thrown inside this function will be reported as a bug.+    await doSomethingAsync()+  },+}+```++Plugins end as soon as their methods end. Therefore you should `await` any asynchronous operation. The following+examples show invalid code and the way to fix it:++```js+// index.js+const { promisify } = require('util')++module.exports = {+  // This callback will not be awaited+  onPreBuild: ({ utils }) => {+    doSomethingAsync((error, response) => {+      console.log(response)+    })+  },++  // This callback will be awaited+  onPostBuild: async ({ utils }) => {+    const response = await promisify(doSomethingAsync)()+    console.log(response)+  },+}+```++```js+// index.js+const pEvent = require('p-event')++module.exports = {+  // This event will not be awaited+  onPreBuild: ({ utils }) => {+    const emitter = doSomethingAsync()+    emitter.on('response', response => {+      console.log(response)+    })+    emitter.start()+  },++  // This event will be awaited+  onPreBuild: async ({ utils }) => {+    const emitter = doSomethingAsync()+    emitter.start()+    const response = await pEvent(emitter, 'response')+    console.log(response)+  },+}+```++```js+// index.js++module.exports = {+  // This callback will not be awaited+  onPreBuild: ({ utils }) => {+    array.forEach(async () => {+      await doSomethingAsync()+    })+  },++  // This callback will be awaited+  onPostBuild: async ({ utils }) => {+    await Promise.all(+      array.map(async () => {+        await doSomethingAsync()+      }),+    )+  },+}+```

I don't think it's clear what the role is of the three different code samples. I think a comment at the top of each one would be helpful.

ehmicky

comment created time in 2 months

Pull request review commentnetlify/build

Update `@netlify/config` `README`

 # Netlify Config -Library for reading netlify configuration files.+Netlify can be configured: -## About+- In the [build settings](https://docs.netlify.com/configure-builds/get-started/)+- In a [`netlify.toml`](https://docs.netlify.com/configure-builds/file-based-configuration/) at the repository root+  directory or base directory -`@netlify/config` brings a wide variety of new functionality to Netlify's config ecosystem.+This library loads, validates and normalizes the Netlify configuration.
This library loads, validates, and normalizes the Netlify configuration.
ehmicky

comment created time in 2 months

Pull request review commentnetlify/build

Update `@netlify/config` `README`

 # Netlify Config -Library for reading netlify configuration files.+Netlify can be configured: -## About+- In the [build settings](https://docs.netlify.com/configure-builds/get-started/)+- In a [`netlify.toml`](https://docs.netlify.com/configure-builds/file-based-configuration/) at the repository root+  directory or base directory
- In the [build settings](https://docs.netlify.com/configure-builds/get-started/).
- In a [`netlify.toml`](https://docs.netlify.com/configure-builds/file-based-configuration/) file in the repository root
  directory or site base directory.

Adding periods to the end of the bullets to help differentiate from the following sentence. Also adding a few extra words for greater clarity.

ehmicky

comment created time in 2 months

issue commentnetlify/build

Allow plugins to surface output information

And for a bit more detail on the "optional" handling:

  • title: optional; defaults to "[Plugin name] ran successfully"
  • summary: required
  • text: optional; if absent, deploy summary line is not expandable

Looking at GitHub's docs for their outputs object, I see that they set the title as required. I'd be totally fine with that, too, if we want to extend the consistency.

ehmicky

comment created time in 2 months

issue commentnetlify/build

Allow plugins to surface output information

@vbrown608 That naming structure sounds great! Makes sense to keep consistency across platforms.

ehmicky

comment created time in 2 months

issue commentnetlify/build

Allow plugins to surface output information

I think your reasoning makes sense on all points, @ehmicky.

Regarding which fields should be required, we could actually make title optional, because the design includes a default version: "[plugin name] ran successfully". I agree that details can be optional, so that leaves description as probably being required. (Otherwise, why have an output at all?)

Regarding title, I wonder if heading might give people a better sense of the purpose/location of the content? I don't want them to think that they should just have the "title" of the plugin there. (Then again, "heading" is likely to be misspelled as "header", so unless we have an alias or something to handle it, maybe it's not worth the potential friction.)

ehmicky

comment created time in 2 months

PR opened publicsuffix/list

Remove domains from Netlify entry: bitballoon.com and netlify.com
  • [x] Description of Organization
  • [x] Reason for PSL Inclusion
  • [ ] DNS verification via dig
  • [ ] Run Syntax Checker (make test)

Description of Organization

Organization Website: https://www.netlify.com/

I'm Jessica Parsons, staff technical writer at Netlify. Netlify is a platform people use to build, deploy, and serve websites.

Reason for PSL ~Inclusion~ Removal

This is a follow-up to #1012, where we added netlify.app as the new domain for Netlify customer sites. The migration is now complete; netlify.com is now used for Netlify-owned properties only, and bitballoon.com is no longer in use (permanently redirects to netlify.com/netlify.app).

DNS Verification via dig

Will configure and post when I have a PR number.

make test

My laptop doesn't have the proper dependencies, so I'm filing as draft to let Travis do the work. 😄 I'll un-draft after Travis passes and I have the PR number for the DNS verification.

+0 -2

0 comment

1 changed file

pr created time in 3 months

create barnchverythorough/list

branch : edit-netlify-entry

created branch time in 3 months

issue commentnetlify/build

Build plugins do not work on Node 6 (or earlier)

Working on a discussion issue for that today!

ehmicky

comment created time in 3 months

issue commentnetlify/build

Automatic installation of plugins makes build much slower

One small thing to consider if going the route of adding to an existing package.json to install plugins: not all repos will have a package.json, so the process would have to account for creating one (or just running the npm install xyz command) if one doesn't already exist.

ehmicky

comment created time in 3 months

issue openednetlify/build

Allow context sensitive build plugins config in netlify.toml

Which problem is this feature request solving? We don't always want to enable a plugin in all deploy contexts. For example, a sitemap plugin might only be useful on production deploys, or you might want a testing plugin to behave differently in different contexts.

We can't do that currently, because plugins are only defined at the top level, e.g.:

[[plugins]]
package = "@netlify/plugin-sitemap"

[[plugins]]
package = "netlify-plugin-cypress"
inputs = { record = false }

Describe the solution you'd like It would be nice if we could store different plugin configs in different deploy contexts in the netlify.toml file. For example:

[[context.production.plugins]]
package = "@netlify/plugin-sitemap"

[[context.production.plugins]]
package = "netlify-plugin-cypress"
inputs = { record = false }

[[context.deploy-preview.plugins]]
package = "netlify-plugin-cypress"
inputs = { record = true }

Describe alternatives you've considered 🤔 A person could make multiple sites, with one for each deploy context.

Can you submit a pull request? No, but I can write the docs for it. 😉

created time in 3 months

PR opened verythorough/eye-chart

Create README.md
+2 -0

0 comment

1 changed file

pr created time in 3 months

create barnchverythorough/eye-chart

branch : verythorough-patch-1

created branch time in 3 months

issue openednetlify/plugins

Add guidelines for plugin authors seeking inclusion in the list

@ehmicky has summarized common plugin issues in a separate issue comment. We can convert this information into a checklist of items needed before submitting a PR to add a plugin to the list.

We could add the content to the README (or contributor guide?), and could also benefit from putting the checklist into a PR template.

Auto-linting would be great, too, but until then, guidance works. :)

created time in 3 months

pull request commentnetlify/plugins

Add ENV plugin

@cball your idea sounds great! I totally skipped over the suffix part of the description 🤦 If you'd like something a little shorter, you could consider contextual instead of context-specific, but it's your plugin, so it's up to you!

cball

comment created time in 3 months

pull request commentnetlify/plugins

Add ENV plugin

This is awesome, @cball ! Can I suggest giving your plugin a more descriptive name? "Env" could mean anything related to env vars. Maybe something like Env Context Prefixer/env-context-prefixer?

cball

comment created time in 3 months

more