Prisma1: Option to ignore certain files for bundling / deploying

[SindreSvendby]

Current behavior
Running graphcool deploy takes along time if you many/large files in your repo, becuase it bundles and pushes everything in the repo:
Example output from DEBUG="*" graphcool deploy

Bundling functions...  bundler added files [ '.babelrc',
  '.eslintrc.json',
  '.flowconfig',
  '.git/',
  '.gitignore',
  '.graphcoolrc',
  '.next/',
  '.storybook/',
  '.travis.yml',
  '.vscode/',
  'LICENSE',
  'Procfile',
  'README.md',
  'components/',
  'flow-typed/',
  'functions/',
  'graphcool/',
  'graphcool.yml',
  'lib-types/',
  'libs/',
  'mocks/',
  'next.config.js',
  'node_modules/',
  'package-lock.json',
  'package.json',
  'pages/',
  'static/',
  'stories/',
  'types/',
  'types.graphql',
  'yarn-error.log',
  'yarn.lock',
  '.build/build.zip',
  '.build/dist/',
  '.git/COMMIT_EDITMSG',
  '.git/FETCH_HEAD',
  '.git/HEAD',
  '.git/branches/',
  '.git/config',
  '.git/description',
  '.git/hooks/',
  '.git/index',
  '.git/info/',
  '.git/logs/',
  '.git/objects/',
  '.git/refs/',
  '.git/packed-refs',
  '.next/BUILD_ID',
  '.next/build-stats.json',
  '.next/app.js',
  '.next/bundles/',
  '.next/commons.js',
  '.next/dist/',
  '.next/main.js',
  '.next/manifest.js',
  '.storybook/.babelrc',
  '.storybook/addons.js',
  '.storybook/config.js',
  '.storybook/preview-head.html',
  '.vscode/settings.json',
  'components/ComponentFinder.js',
  'components/OpacityContainer.js',
  'components/Screen.js',
  'components/admin/',
  'components/lineup/',
  'components/playerlist/',
  'components/scoreboard/',
  'components/svgs/',
  'flow-typed/npm/',
  'functions/getFullInfoOnMatch/',
  'functions/getLineup/',
  'functions/getPlayerInfoToServe/',
  'graphcool/node_modules/',
  'graphcool/package.json',
  'graphcool/yarn.lock',
  'lib-types/animated.js.flow',
  'lib-types/next.js.flow',
  'libs/color.js',
  'libs/initApollo.js',
  'libs/setUtils.js',
  'libs/withData.js',
  'mocks/players.js',
  'mocks/screens.js',
  'mocks/state.js',
  'mocks/teams.js',
  'pages/_document.js',
  'pages/admin.js',
  'pages/index.js',
  'static/icon/',
  'stories/admin/',
  'stories/lineupStory.js',
  'stories/playerlist/',
  'stories/scoreboardStory.js',
  'stories/screenStory.js',
  'types/types.js',
  'node_modules/.bin/',
  'node_modules/.cache/',
  'node_modules/.yarn-integrity',
  'node_modules/@hypnosphi/',
  'node_modules/@storybook/',
  ... 190820 more items ] +40s

Reproduction
Repo that takes 7 min to deploy
Repo with same files that takes 5 sekunds to deploy (hash:
b25fde4f on master)

Current Workaround
Current workaround is to create a subfolder and move all graphcool files to this files, create a separate package.json that contains the dependencies of your graphcool functions,

Expected behavior?
Every require/import found in the files referenced from the functions part of the graphcool.yml files is recursived bundled, but not anything else.

Other solutions
Could have a ignore file, or just include node_modules and the files referred to.
It is possible to think of several black/white list options here. But I think what I'm suggestion under Expected behavior is the correct way to do this.

Open questions

• Is the bundling only done to get graphcool specific files and imports for the functions? Or am I missing a key point here?

[marktani]

Current Workaround
Current workaround is to create a subfolder and move all graphcool files to this files, create a separate package.json that contains the dependencies of your graphcool functions,

This is no workaround. This is the recommended way of doing it at the moment.

But I agree, a way to ignore certain files for bundling/deploying would be very useful! 🙂

[kbrandwijk]

I already have a .gitignore and a .npmignore, so there's always room for a .gcignore

[SindreSvendby]

ok, then I think I misunderstood you on Slack @marktani

I was not able to find any documentation mention this. But could it is documented good in the right place. I'm notoriously bad at reading docs. If you are happy with the documentation on this I would just close this issue!. To have it in it's own folder is just a good thing I think. There are a issues around here, but if the docs are clear then it's not a big problem

[marktani]

In that case, do you think we can close this issue in favor of https://github.com/graphcool/framework/issues/816?

[SindreSvendby]

Indeed, this is redundant. I'm closing this.