Scan built files and inline critical CSS via https://github.com/addyosmani/critical

this is one of those hot issues that woudl be nice to have a first class soln for netlify/build-image#196

i see in the readme there's also this issue https://github.com/netlify/product/issues/121

lighthouse results aren't stable. we can offer to do multiple runs in parallel and average them?

so lets say i have a v1 site

then i develop a v2

i use this plugin to put v1 into cache, and namespace it into foo.netlify.com/v1 and then v2 takes over the root.

so on and so forth

i dont know what the api would look like but i think this would be handy

a lot of people use branch deploys for this and maybe they dont have to

This is not an important issue at all, but I was wondering if we could rename the directories of the packages. Mostly because it's currently a little annoying when doing lots of cd in the terminal:

• @ needs to be backslash-escaped first to allow Tab-autocomplete
• netlify-plugin-* requires two Tab autocompletions (one for netlify-plugin-, a second for the rest of the name).

My suggestion is:

• @netlify-build|config -> build|config
• netlify-plugin-{name} -> {name}

This is for the directories names only, not the npm package names.

The reason I am not submitting a PR yet is to avoid merge conflicts.

Post build inject prefetch, preload, etc tags for popular pages based on site analytics.

https://guess-js.github.io/

Using machine learning + analytics data to make sites load smarter

We need a caching utilities method to help users get, save, and delete items from the cache folder in between builds.

The cache locally would be in .netlify/cache and in remote CI it would be in /opt/build/cache/ (/opt/build/cache/ is current cache folder in netlify buildbot)

All the methods should fail gracefully.

The save should create directory paths if they don't exist etc.

get: filePath => {
  console.log('get cache file')
},
save: (filePath, contents) => {
  console.log('save cache file')
},
delete: filePath => {
  console.log('delete cache file')
}

Phil created his own for use in his plugin https://github.com/philhawksworth/netlify-plugin-fetch-feeds/blob/master/index.js#L17 many users will need this functionality

This could live in @netlify/build or be a new package. @netlify/utils (something like this)

Why is zip and ship installed twice?

Here https://github.com/netlify/build-image/blob/9e0f207a27642d0115b1ca97cd5e8cebbe492f63/Dockerfile#L348
and https://github.com/netlify/build-image/blob/9e0f207a27642d0115b1ca97cd5e8cebbe492f63/run-build-functions.sh#L495

brought up in donut today with @fool https://github.com/netlify/build-tests

after wasting about 30 mins debugging builds today i realized that a watch mode for netlify-build would be quite nice.

i'm not 100% sure we need it - could we just use nodemon to do the same thing? or what else can we add to a watch mode that nodemon wouldn't know about? (i think its likely we can add things, thats why i am opening this issue)

there's technically a deploy lifecycle so really we should move any blocking things to saveCache, manifest, and finally, however a lot of people will be abusing postbuild to do stuff and wonder why their deployments are slow.

so this issue just tracks two things:

• make sure saveCache, manifest, and finally dont actually block "site going live"
• how to warn against people misusing postbuild to shoot themselves in the foot

Simplified Build Env

The folder structure of the build environment is also being revamped to streamline & simplify how users interact with it.

Proposed structure:

• .netlify - Main folder
• .netlify/src - Source code from repo, zip, tar
• .netlify/cache - Files persisted across builds
• .netlify/cache/dependencies - All dependencies are cache here. These are used for lookup / install process.
• ? .netlify/build - Built files

These values would be available via plugin constants as well

At the moment the syntax for the plugins configuration property is:

plugins:
  - netlify-plugin-functions:
      enabled: false
  - ../../my-plugin:
      enabled: true

I think representing a collection by using first an array then a single-property object is a little uncommon and adds one level of indentation.
Also using file paths as object keys feels a little wrong (or is that just me?).

What do you think of the following alternative?

plugins:
  - name: netlify-plugin-functions
    enabled: false
  - path: ../../my-plugin
    enabled: true

On one hand it requires typing one more word. On the other hand, I think this is visually clearer and feels simpler to grasp for the end user.

This also allows us to separate different loading strategies into different properties. IMHO a single polymorphic property is harder to learn that several monomorphic properties. At the moment we only have two loading strategies (by name and by path) but this would make adding more easier.

Another advantage is, if we were to pass the list of plugins to the end user, we would probably normalize it to the above shape anyway. It would be then be easier for the user to get the same shape as the one they defined in netlify.yml instead of a different one.

Finally this is easier to parse and manipulate when the netlify.yml is loaded programmatically (which users might do). It's also easier to validate and do static analysis on.

The initial idea is to start by reworking the complex bash script that actually drives the build command, including dependency installs and build caching.

https://github.com/netlify/buildbot/blob/master/script/run-build.sh

Replacing this with a node.js script would be a good start towards being able to rely on the same modules across netlify-dev and the buildbot process.

This would be much easier to test and iterate on than a pure bash script, and we can then use that a starting point for implementing things like addon provisioning, toml processing, pre build / post build stages, etc...

• Old build flow https://github.com/netlify/netlify-build/tree/master/old
• New script https://github.com/netlify/netlify-build/blob/master/src/index.js

JAVA_VERSION=default_sdk

default_sdk what is this?

https://github.com/netlify/build-image/blob/f9c7f9a87c10314e4d65b121d45d68dc976817a2/run-build-functions.sh#L295

Getting some console.log issues when trying to log out an execa subprocess in a plugin.

async function runThing(cmd, opts) {
  const cwdPath = resolveConfigPath(opts.config)
  const subprocess = execa(`${cmd}`, {
    cwd: cwdPath,
    shell: true,
  })
  subprocess.stdout.pipe(process.stdout, { end: true })
  try {
    const { stdout } = await subprocess
    return stdout
  } catch (err) {
    console.log(subprocess)
    throw new Error(err)
  }
}

Stack trace:

 err TypeError: obj.hasOwnProperty is not a function
    at DeepMap.mapObject (/Users/davidwells/Netlify/projects/build/netlify-build/packages/@netlify-build/node_modules/deep-map/lib/deep-map.js:49:21)
    at DeepMap.map (/Users/davidwells/Netlify/projects/build/netlify-build/packages/@netlify-build/node_modules/deep-map/lib/deep-map.js:27:45)
    at DeepMap.mapObject (/Users/davidwells/Netlify/projects/build/netlify-build/packages/@netlify-build/node_modules/deep-map/lib/deep-map.js:50:36)
    at DeepMap.map (/Users/davidwells/Netlify/projects/build/netlify-build/packages/@netlify-build/node_modules/deep-map/lib/deep-map.js:27:45)
    at deepMap (/Users/davidwells/Netlify/projects/build/netlify-build/packages/@netlify-build/node_modules/deep-map/lib/deep-map.js:16:40)
    at redactValues (/Users/davidwells/Netlify/projects/build/netlify-build/packages/@netlify-build/src/utils/redact.js:13:10)
    at args.map.a (/Users/davidwells/Netlify/projects/build/netlify-build/packages/@netlify-build/src/utils/patch-logs.js:26:29)
    at Array.map (<anonymous>)
    at Object.apply (/Users/davidwells/Netlify/projects/build/netlify-build/packages/@netlify-build/src/utils/patch-logs.js:15:33)
    at runThing (/Users/davidwells/Netlify/projects/build/netlify-build/example/plugins/serverless-plugin/index.js:61:13)

It appears that deep-map logic doesn't like this object

a plugin that bundles a bunch of common checks that newbies might forget to do (typically webpack related), for example:

• large initial load bundle
• not vendoring js chunk
• loading styles in js instead of with style-loader

https://www.youtube.com/watch?v=V9dZ8dHwX50&list=WL&index=68&t=99s

Maybe just my IDE but I'm seeing this in build/bin.js

Temporarily disabled this via /* eslint-disable node/no-unpublished-bin,node/no-unsupported-features */

Is node 4 set as a version somewhere in dev tooling?

this is one of those hot issues that woudl be nice to have a first class soln for netlify/build-image#196

In an effort to speed up build times, we need to trim down the build image used as much as possible.

Having advanced heuristics of what the projects needs to run should help.

There are a couple of different methods we can use for this:

• Parsing & resolving build commands
• Leveraging https://github.com/netlify/netlify-dev-plugin/tree/master/src/detectors
• Allowing users to specify runtimes needed as env variables.
• Allowing users to specify custom docker images

We could also run the first build with the kitchen-sink image and use ML to optimize the image on the next run

What's our strategy for Node.js versions?

This issue is not about how do we implement it (transpiling, etc.) nor which specific version we want to target, but about the requirements, i.e. what do we need to support from a business/end-user standpoint?

We have three parts that could be thought independently when it comes to Node.js versions:

1. Our code
2. User's code (build commands and lifecycles)
3. Plugins code

At the moment those three parts use the same Node.js version. Since we run each of those parts in different processes, we could technically use different Node.js versions so they are decoupled in that respect.

The reason is that each part has different business requirements:

1. Our code should probably use the latest Node.js versions:
   a. To benefit from security fixes. Node.js security patches only apply to the latest minor/patch versions of each major release. Being stuck on let's say 8.3.0 means we don't get any of those.
   b. To benefit from the speed boost of the new V8 releases. Newer Node.js releases can be significantly faster.
   c. To be able to update our dependencies. Most dependencies follow the Node.js release cycle. For example most libraries have now dropped support for Node 6/7, and we can expect Node 8/9 to follow the same fate in about one year.
2. User's code should use whatever the user wants. We should not force them to a specific Node.js version. This is valid not only for Node.js but for other runtimes.
3. For plugins code, we want to make sure older and not well maintained plugins still work even as our main code moves forward.

For this reason, I think we should probably run those different parts with different Node.js versions. What do you think?

We need a utility for verifying & validating user config. Something like https://github.com/airware/asl-validator but for the allowed values of the resolved object from a netlify.[toml] file

This utility can be used by multiple packages build/cli/dev etc.

We can also use this schema as source of truth to generate the documentation so there isn't ever a mismatch or missing values.

Initially we can verify off https://www.netlify.com/docs/netlify-toml-reference/ values.

Create a Netlify build plugin that allows users to provision MongoDB atlas databases for a site.

The user will need to supply their mongo API key from atlas.

The first time it runs, it will create a database instance

Example config:

plugins:
  - mongo:
       databaseName: 'xyz'
       MONGO_API_KEY: ${env:mongokey}
       ...

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

- What is the current behavior?
hard crash on misconfiguration

- What is the expected behavior?
https://www.npmjs.com/package/jest-validate

We need a standard naming convention for plugins.

There are 2 types of plugins:

• Internal plugins releases & maintained by Netlify
• External community plugins

Internal

Possible conventions:

@netlify/xyz-plugin

@netlify/build-plugin-xyz

External

netlify-plugin-xyz

netlify-xyz-plugin

Standardizing around netlify-plugin-{name} will make it easier for people to find plugins on NPM

Should the GitHub repository be renamed from netlify/netlify-build to netlify/build?

Not very important issue, but I was wondering.

Discussed here #94 (comment)

Make lifecycle hooks camelcase by default (and how we doc them) but allow for lowercase

Preferred:

preBuild
build
postBuild

Allowed but not encouraged:

prebuild
build
postbuild

Pre build scan dependencies for security issues via https://snyk.io

Other CI/CD config research

Examples of other CI/CD configuration files.

• Travis
• AWS codeBuild
• GCP cloudBuild
• Circle CI
• Codeship CI
• Github Actions
• Gitlab CI
• Serverless lifecycle
• Other CI tools

Travis

link

Note: named keys like before_install are lifecycle

sudo: required

language: ruby

services:
  - docker

before_install:
  - echo "Testing Docker Hub credentials"
  - docker login -e=$DOCKER_EMAIL -u=$DOCKER_USERNAME -p=$DOCKER_PASSWORD
  - echo "Docker Hub credentials are working"
  - docker build -t build-springxd-base .

script:
  - docker ps -a

after_success:
  - echo "Test Success - Branch($TRAVIS_BRANCH) Pull Request($TRAVIS_PULL_REQUEST) Tag($TRAVIS_TAG)"
  - if [[ "$TRAVIS_BRANCH" == "master" ]]; then echo -e "Push Container to Docker Hub"; fi
  - docker login -e=$DOCKER_EMAIL -u=$DOCKER_USERNAME -p=$DOCKER_PASSWORD
  - export REPO=jayjohnson/springxd-base
  - export TAG=`if [ "$TRAVIS_BRANCH" == "master" ]; then echo "latest"; else echo $TRAVIS_BRANCH ; fi`
  - docker build -f Dockerfile -t $REPO:$COMMIT .
  - docker tag $REPO:$COMMIT $REPO:$TAG
  - docker tag $REPO:$COMMIT $REPO:travis-$TRAVIS_BUILD_NUMBER
  - docker push $REPO

AWS codeBuild

Notes: phases is lifecycle

version: 0.2

phases:
  install:
    runtime-versions:
      java: openjdk8
  build:
    commands:
      - echo Build started on `date`
      - mvn test
  post_build:
    commands:
      - echo Build completed on `date`
      - mvn package
artifacts:
  files:
    - target/my-app-1.0-SNAPSHOT.jar
    - appspec.yml
  discard-paths: yes

GCP cloudBuild video

Note: steps array is lifecycle

steps:
- name: 'gcr.io/cloud-builders/docker'
  args: ['build', '-t', 'gcr.io/my-project/my-image', '.']
  timeout: 500s
- name: 'gcr.io/cloud-builders/docker'
  args: ['push', 'gcr.io/my-project/my-image']
- name: 'gcr.io/cloud-builders/kubectl'
  args: ['set', 'image', 'deployment/my-deployment', 'my-container=gcr.io/my-project/my-image']
  env:
  - 'CLOUDSDK_COMPUTE_ZONE=us-east4-b'
  - 'CLOUDSDK_CONTAINER_CLUSTER=my-cluster'
options:
    machineType: 'N1_HIGHCPU_8'
timeout: 660s
tags: ['mytag1', 'mytag2']
images: ['gcr.io/my-project/myimage']

Circle CI

version: 2
jobs:
  build:
    working_directory: ~/mern-starter
    # The primary container is an instance of the first image listed. The job's commands run in this container.
    docker:
      - image: circleci/node:4.8.2-jessie
    # The secondary container is an instance of the second listed image which is run in a common network where ports exposed on the primary container are available on localhost.
      - image: mongo:3.4.4-jessie
    steps:
      - checkout
      - run:
          name: Update npm
          command: 'sudo npm install -g npm@latest'
      - restore_cache:
          key: dependency-cache-{{ checksum "package.json" }}
      - run:
          name: Install npm wee
          command: npm install
      - save_cache:
          key: dependency-cache-{{ checksum "package.json" }}
          paths:
            - node_modules
  test:
    docker:
      - image: circleci/node:4.8.2-jessie
      - image: mongo:3.4.4-jessie
    steps:
      - checkout
      - run:
          name: Test
          command: npm test
      - run:
          name: Generate code coverage
          command: './node_modules/.bin/nyc report --reporter=text-lcov'
      - store_artifacts:
          path: test-results.xml
          prefix: tests
      - store_artifacts:
          path: coverage
          prefix: coverage

workflows:
  version: 2
  build_and_test:
    jobs:
      - build
      - test:
          requires:
            - build
          filters:
            branches:
              only: master

Codeship CI

Note: lifecycle in seperate file codeship-steps.yml

# codeship-steps.yml
- name: foo_step
  tag: master
  service: app
  command: echo foo
- name: bar_step
  service: app
  command: echo bar

Github Actions

workflow "Build and deploy on push" {
  on = "push"
  resolves = ["zola deploy"]
}

action "zola deploy" {
  uses = "shalzz/zola-deploy-action@master"
  secrets = ["TOKEN"]
  env = {
    PAGES_BRANCH = "master"
  }
}

Gitlab CI

image: ruby:2.3

cache:
  paths:
  - vendor/

before_script:
  - bundle install --path vendor

pages:
  stage: deploy
  script:
  - bundle exec jekyll build -d public
  artifacts:
    paths:
    - public
  only:
  - master

test:
  stage: test
  script:
  - bundle exec jekyll build -d test
  artifacts:
    paths:
    - test
  except:
  - master

Serverless lifecycle & Custom hooks

custom:
 scriptHooks:
   after:package:createDeploymentArtifacts:
     - build/serverless/add-log-subscriptions.js
     - build/serverless/add-dynamodb-auto-scaling.js

buildkite

steps:
  - label: ":hammer: Tests"
    commands:
      - "npm install"
      - "npm run tests"
    branches: "master"
    env:
      NODE_ENV: "test"
    agents:
      npm: "true"
      queue: "tests"
    artifact_paths:
      - "logs/**/*"
      - "coverage/**/*"
    parallelism: 5
    timeout_in_minutes: 3
    retry:
      automatic:
        - exit_status: -1
          limit: 2
        - exit_status: 143
          limit: 2
        - exit_status: 255
          limit: 2

  - label: "Visual diff"
    commands:
      - "npm install"
      - "npm run visual-diff"
    retry:
      automatic:
        limit: 3

  - label: "Skipped job"
    command: "broken.sh"
    skip: "Currently broken and needs to be fixed"

  - wait

  - label: ":shipit: Deploy"
    command: "deploy.sh"
    branches: "master"
    concurrency: 1
    concurrency_group: "my-app/deploy"
    retry:
      manual:
        allowed: false
        reason: "Sorry, you can't retry a deployment"

  - wait

  - label: "Smoke test"
    command: "smoke-test.sh"
    soft_fail:
      - exit_status: 1

Other CI tools

• offer suggestions on fixing, by investigating lighthouse ci cli
• allow people to reference by build ID instead of only alias
• switch persistence path in production

including forms and asset minification

Add env variable support to netlify.toml

Ref: https://github.com/netlify/netlify-config

Is onError only meant to be used within plugins, or is it also available to users as config.build.lifecycle.onError?

encrypt/decrypt files so people can commit yet-to-be-public files to github?

we can use env vars for now, but someday we may want to use netlify secrets.

We need a way to validate improvements are making things speedier!

The proposal here is adding in some benchmarking

Perhaps we can test master branch vs previous published versions of the package and verify the results?

Also a way to verify PRs don't have major perf dips would be awesome 😍

https://www.npmjs.com/package/benchmark might be a good fit for this

(This is a continuation of the discussion of #70)

At the moment template variables (such as ${env:PORT}) always evaluate to strings.

This means it is currently not possible to use template variables with configuration options or plugin options that are numbers or booleans, such as plugin.enabled or plugin.options.port.

We could fix this by coercing the value type.

For example using the following code:

try {
  return JSON.parse(string)
} catch (error) {
  return string
}

This would evaluate hello to string, 5 to number, true to boolean. This would still allow strings that represent numbers or booleans when using double quotes, e.g. "5" or "true".

for "self healing builds"?

specify routes for forms, render the html in puppeteer, pick out forms, programmatically create the forms

open question: how to create the forms inside netlify-build?

ANOTHER APPROACH: just directly name the forms without bothering to render and trust that the names will match

https://github.com/netlify/netlify-build/blob/master/src/install/go/gutenberg.js

Project seems dead. Perhaps time to chuck it and see if anyone misses it?

Scaffold.js is a re-implementation of these 2 bash scripts:

• https://github.com/netlify/buildbot/blob/master/script/run-build.sh
• ^ ran by run-build.sh https://github.com/netlify/build-image/blob/xenial/run-build-functions.sh

This bash script is responsible for the "magic" of the build image where you give it a repo and it just works ™

Under the hood it's:

• Creating directories in the build image
• Fetching caches dependancies & binaries from previous runs
• Installing various versions of runtimes
• Installing static site generator dependancies
• Running the build.cmd (will be taken over by @netlify/build)
• Saves the dependancies etc to cache for next run.

run-build.sh and https://github.com/netlify/netlify-build/blob/master/packages/%40netlify-build/src/scaffold.js have this logic.

We need to get the new node package working inside the https://github.com/netlify/build-image so we can continue iterating on it and eventually replace the giant bash script with maintainable node script.

I was able to get it running locally in docker, but there are some pieces that are missing in Ruby/Go installers.

docker run -it -v $PWD:/netlify/src netlify/build /bin/bash

There are also many places we can optimize this script and run things concurrently instead of everything synchronously one after the other.

TLDR;

• Get scaffold running in https://github.com/netlify/build-image
• Refactor code for concurrency
• Add tests to verify cache fetched correctly, dependancies installed correctly, etc.

Note: this won't run locally on a users machine, only in a CI context in a docker image. This is due to the fact it does a lot of changes to binaries, deps, etc. and we don't want to break anyone's computer 😃

scan deployed files for all html files, save them with an ID

on new build, rescan and diff (vs specified ID or previous build), and yell at user if any missing files aren't accounted for via redirects.

(optional) fuzzy algo to suggest redirects for user to copy and paste in case files simply moved.

clientside routes are ofc out of scope.

In an effort to support future UI work in app.netlify.com, we need to allow for plugins to output logs.

These logs will:

• Be consumed by netlify UI
• Be shippable to third party logging systems
• ...

The idea is to capture console.log and any other output returned from plugins and save them to a structured log file.

Those structured log objects should:

• be converted to human-friendly console output. I.e. the user does not see them, they are under the hood.
• be output to files
• be passed to plugins such as log shipping plugins

if this is a thing we're going to go there eventually, so might as well have this discussion now.

can take the form of single-level "presets" like babel does or "plugins all the way down" like gatsby does

This looks amazing and I can't wait for these stages to be configurable (I don't actually know if that is on the roadmap, but it would solve/mitigate a lot of problems that we'll talk about tomorrow). This however seems like something worth checking on right now:

In Looking at https://github.com/netlify/netlify-build#lifecycle I see a "parseconfig" step at the beginning - but it also needs to happen at the end to grab changed redirects/header files from netlify.toml during build. This is a pattern that a fair number of customers use (we know, because they usually write in for help setting it up).

Just wanted to make sure it was considered! Seems like we'll be parsing _headers/_redirects then anyway so maybe an easy bolt-on or maybe already included in the manifest step or something.

Pre build scan repo source code for exposed secrets via https://github.com/auth0/repo-supervisor

Add netlify build CLI command

We need a nice way to figure out different information about a project from its source code.

@netlify/heuristics (working title) would be the module that detects what kind of a project the repo is, including:

• The type of static generator used
• The functions setup (what runtime JS or Go)
• What binaries are used in the build.command See https://github.com/netlify/netlify-build/tree/master/packages/%40netlify-build/src/heuristics
• If nvmrc is set what version of node does this project expect
• Is there a requirements.txt file to indication its a python based project
• Information (if available) on what the remove git provider is, github/gitlab/bitbucket.

Any information that we need to:

1. Use in the scaffolding flow
2. Use in netlify dev
3. Use in netlify build. Plugins might want to have this heuristic information

Currently there is https://github.com/netlify/cli/tree/master/src/detectors living in the CLI and https://github.com/netlify/netlify-build/tree/master/packages/%40netlify-build/src/heuristics inside the build package.

Todo:

• Extract this into a package in this repo
• Include & potentially refactor detectors
• Include additional information we have access to listed above & any other ideas that we think would be handy for consumers (in build, build plugins, & netlify dev)
• Use dependency in CLI

Notes: https://github.com/netlify/cli/tree/master/src/detectors is using alot of sync calls and the API might need to be revisited to avoid false positives.

This is awesome! The build plugins are so much fun to play with. @DavidWells asked for some feedback, here's what I've seen from writing a couple so far.

• It would be nice to have a hook to detect whether the build has failed, (separate from the lifecycle hooks). The builds are non-deterministic enough to warrant it because everyone's build is going take slightly different amounts of time, detection of whether the process has halted wouldn't be as efficient.
• There's something inconsistent about how plugins build locally and via NPM. I'm not sure it's installing plugins via node modules (can show you stack traces if you'd like to see what I'm saying).
• Both @sw-yx and @philhawksworth ran into an issue needing to persist data across builds, they can fill in more details here, Phil did a PoC in his build plugin example.

It's really fun to work with! Thanks for making this. 🤘

Netlify Build is flexible & built to support any kind of build flow.

It has a pluggable lifecycle that users can hook into to customize how the build operates

Build Lifecycle

The build lifecycle contains these hooks.

• init - Build initialization
• configParse - Parse netlify config & resolve any dynamic configuration
• getCache - Fetch previous build cache
• install - Install project dependencies
• build - Project build step
• package - Create build artifact
• deploy - Deploy built artifact
• saveCache - Save cached assets
• manifest - Outputs manifest of resources created
• finally - Last step in deployment chain

Hooks have pre and post hooks attached to them as well.

For example, preinstall runs before install and postinstall runs directly after install.

pre{hook} --> {hook} --> post{hook}

prebuild --> build --> postbuild

https://github.com/netlify/netlify-build/tree/62af3eab11852ce8e0b59cd9ae5b99b4ea23a85f#lifecycle

Links

• pre config https://community.netlify.com/t/variable-setting-before-deploy/1416
• pre build netlify/build-image#323

In an effort to have better mono repo support

We need a more effective default caching strategy.

If node_modules are installed in sub folders (sub site or function dirs) we need to cache those by default

Refs:

• #5
• mono-repos, related, ref