Currently on my machine, vercel --version takes 850ms to run. With this change, that execution time is reduced to ~550ms.
The reason is that source maps seem to significantly slow down Node.js execution, compounded by the size of the source map, even if it is not used.
I believe the benefits of this perf improvement outweigh the direct source maps and minification benefits.
If it is felt that direct per-file source maps are necessary for internal errors, then reducing the source map size should be investigated further to improve the runtime performance here.
This PR updates the `README.md` files with the following changes:
- Removal of CLI deployment.
- Amends Blitz.js to be in line with other `README.md` formats.
* Revert "[build-utils] Use `handle: error` for api 404 (#5064)"
This reverts commit 02e1c921ac.
* Re-enable cli changes
* Re-enable redwood changes
* Minor cleanup
Since released PR #5009, we had some users that depend on the broken behavior. This adds an arbitrary date so that old projects will use the old broken behavior, and new projects will use the new behavior from #5009.
The reason for the date is that we don't want to force users to create new projects who noticed this broken behavior months ago like this discussion: https://github.com/vercel/vercel/discussions/4138
Its better to be a bit aggressive and set the date far back because users with that want the old behavior have a workaround: select Next.js in the framework dropdown. However, users that want the new behavior with an old project will be stuck without a solution.
This PR does a few things:
- Consolidates build-utils to use both 404 routes in `handle: error` phase
- Fixes `vc dev` to process `handle: error` phase after the `handle: filesystem` phase
- Updates `/api` 404 route to be excluded for frameworks like RedwoodJS which use their own functions
The deployment API might return a learn more link to address warnings, tips, or notices
CH-568
```
HTTP/2 200
...
x-vercel-warning-bad-error: Something went wrong
x-vercel-link-bad-error: https://vercel.link/bad-error
x-vercel-notice-low-funds: You are low on funds
x-vercel-link-low-funds: https://vercel.link/increase-funds
...
```
Should output as:
```
Warning: Something went wrong
Learn More: https://vercel.link/bad-error
Notice: You are low on funds
Learn More: https://vercel.link/increase-funds
```
This pull request adds a method redirect, the behavior will be the same as that of Next.js with `pages/api`. This PR takes into account the change that is being made in Next.js with redirect due to the [error that was reported](https://github.com/vercel/next.js/issues/15594) a few hours ago.
Co-authored-by: Steven <steven@ceriously.com>
This corrects behavior that was changed when switching to use `safelyCompile` which caused some `path-to-regexp` replacing behavior to be changed like not removing brackets `{}` around params which are removed in Next.js. This updates to first attempt to use the normal replacing behavior from `path-to-regexp` falling back to the safe compiling logic added when that fails.
Additional tests have been added to ensure the brackets are stripped as expected when compiling with `path-to-regexp`
The update message was sometimes printed when there was no update.
This PR fixes the update check to ensure the that it is only printed when the latest version differs from the current version.
This fixes the case where `trailingSlash: true` is used with `next export` causing the `404` page to be output as `404/index.html` and we were previously only checking for the 404 output at `404`. This also adds a regression test for this behavior.
Closes: https://github.com/vercel/next.js/issues/16218
The CLI doesn't depend on `@vercel/redwood` for `vc dev` since PR #5036 so we can remove it.
Similarly, zero config does not install `@vercel/next` or `@vercel/static-build` during `vc dev` so these can be removed too.
In the case where the user defines `builds` in vercel.json, the runtimes will be installed during the first run of `vc dev`.
This updates to not automatically append params to the query for rewrites if one or more of the params are already used in the destination's path. No other behavior is being changed and if the user still wants the params in the query after using them in the destination's path they can manually add them like with redirects.
x-ref: https://github.com/vercel/next.js/pull/16189
This PR uses the the new property added in PR #5034 to determine if a framework has a frontend runtime defined.
It also reverts a couple workarounds add in PR #4937 which was added for RedwoodJS which is no longer necessary since RedwoodJS defines a frontend framework the same way Next.js does.
This PR adds two properties to `frameworks.json`:
1. `useRuntime` - this moves the special case for non `@vercel/static-build` frontends, so that any framework can do the same as Next.js and RedwoodJS
2. `ignoreRuntimes` - this allows a framework to opt out of api detection such as RedwoodJS which handle's its own `.js` extensions
This also fixes 2 bugs discovered during implementing the feature:
1. `test-unit.yml` was not testing Node 12, it was testing 10 for both runs
2. `sortFilesBySegmentCount()` was non-deterministic causing node 10 and 12 to sort differently
This PR updates the default build command per @thedavidprice
It also uses `@vercel/frameworks` as a source of truth for the build command.
If the user has a `build` script in `package.json`, that will take precedence over the default.
Some files require execution privileges, such as Prisma, so we must preserve the file mode.
We also want redwood to behave the same as other frameworks and use `yarn build` if available.
CH Story:
https://app.clubhouse.io/vercel/story/5291/cli-connection-pooling
(Mac) script for watching count of active connections to API:
`watch -n 0.1 'netstat -a -n | grep -E \'(13.52.46.156|52.9.164.177)\' | wc -l'`
Limiting the active connections to 50 greatly decreased the amount of active connections but did not noticeably increase the time to upload files.
For each semaphore size below, I tested uploading 200 files of random size (between 50kb and 100kb) 5 times. More tests on varying file sizes / amounts showed similar results.
Results:
```
Size: Average time in ms
50 : 25740 ms
700 : 28763 ms
10 : 29339 ms
```
I also moved the the agent creation outside of the forEach loop when uploading. This is functionally the same (as node would use the same socket for the same hostname) but makes it easier to access the agent object if we need to debug in the future, and it seems unnecessary to create a new object each call.
This fixes the scenario where 1) is Windows and 2) there is no
`.gitignore` file in the project, so `vc link` creates one. Before, it was
defaulting to `\n`. Updated to use `os.EOL` so that `\r\n` is used on
Windows.
Also removed `encoding` option to `writeFile()` since `utf8` is already the
default.
Related to #4965.
We don't need to report these errors to Sentry because the user attempted a command that requires them to login.
https://sentry.io/organizations/vercel/issues/1498276418/?project=1323225
This will print:
- `NOT_AUTHORIZED`: "The specified token is not valid. Use vc login to generate a new token."
- `TEAM_DELETED`: "Your team was deleted. You can switch to a different one using vc switch"
### Related
- Related to #4082
- Related to #3857
* [cli] Adjust output for recently changed domain commands
* Update the inspect and list page
* Remove test
* Update packages/now-cli/src/commands/domains/inspect.ts
Co-authored-by: Steven <steven@ceriously.com>
* Change output
* Remove workaround
* Update error
* Include contextName
Co-authored-by: Steven <steven@ceriously.com>
This makes sure the routes mapping to the serverless functions handle the trailing slash being present or not. This also adds additional test cases to ensure it is functioning correctly
This adds handling for more cases while updating header values to make sure to escape any characters that could break compiling with `path-to-regexp`
x-ref: https://github.com/vercel/next.js/pull/15592
This makes sure we detect a fully static `/index` page correctly since the `prerender-manifest` lists it as `/` and we were expecting `/index` during the lambda building opt-out check
x-ref: https://github.com/vercel/next.js/discussions/15619
This PR fixes a bug when running `vercel link` command in a directory with `vercel.json` that contains `builds` property. The problem is that framework auto-detection doesn't run when `builds` is used, only for zero config. So we skip the API and instead create the project without auto-detection during `vc link`.
This updates our Next.js test fixtures to run against canary.
It looks like the mono-repo fixtures will need to be updated to run against canary separately since there may be a conflict with legacy routes and the trailing slash redirect
* [client] Export `buildFileTree()` and return the ignore list
The ignore list from this function will be used in production to
render a warning if there are files listed in the `.vercelignore` file
that are being comitted to the project's git repo.
* Tests for `ignoreList`
* Update packages/now-client/src/utils/index.ts
Co-authored-by: Steven <steven@ceriously.com>
Co-authored-by: Steven <steven@ceriously.com>
Previously, the zero detection would see js files in the `/api` directory and attempt to use `@vercel/node`. However, this doesn't work with RedwoodJS which uses a different format for [`/api`](https://github.com/vercel/vercel/tree/master/examples/redwoodjs/api) so we must only use `@vercel/redwood` when RedwoodJS is detected.
## Problem
`api-frameworks` is not being cached by our edge when used via the fallback-to-front mechanism. That's because the headers are only applied to `/api/frameworks` but not `/api/v1/frameworks` which is the actual path being used.
## Solution
Also apply the caching headers to `/api/<version>/frameworks`
* [now-cli] Change `now domains add` workflow to match dashboard
* Fix error throwing and add --force
* Remove `now domains verify`
* Count projects when removing a domain
* Include projects for `now inspect`
* Updated `now domains ls`
* Fix `now domains ls`
* Use Finally
* Add tests
* Use --force for domain tests
* Adjust tests
* Adjust test and fix output
* Fix padding
* Adjust more tests
* Ensure the project exists
* Log the deployment
* Fix tests again
* Remove project after test
* Fix command
* Fix test
* Change user after a couple of tests
* Add check
* Use random name for domain
* More logging
* Add more logging
* Remove logging
* Remove .now/project.json every time
* Skip test
* Add test to change user
* More logging
* Use now login
* Remove duplicated test
* Consider linked project for `domains add`
* Fix linting
* Remove unused docs
* Undo changes
* Undo more changes
* Fix typo
* Do not sort projects when there is only one record
* Fix loop
* Deploy with `-V 2`
* Remove verification
* Remove outdated link
* Update packages/now-cli/src/commands/domains/add.ts
Co-authored-by: Steven <steven@ceriously.com>
* Update packages/now-cli/src/commands/domains/add.ts
Co-authored-by: Steven <steven@ceriously.com>
* Use utils for public suffix and service type
* Update packages/now-cli/src/commands/domains/ls.ts
Co-authored-by: Steven <steven@ceriously.com>
* Update packages/now-cli/src/commands/domains/add.ts
Co-authored-by: Steven <steven@ceriously.com>
* Change link
* Undo test changes
* Fix type issues
* Update packages/now-cli/src/commands/domains/add.ts
Co-authored-by: Steven <steven@ceriously.com>
* Use domain config to print info
* Check apex domain when removing a domain
* Remove psl
* List projects when removing a domain
* Do not list projects
* Change user earlier
* Update packages/now-cli/src/commands/domains/inspect.ts
Co-authored-by: Steven <steven@ceriously.com>
* Apply suggestions from code review
Co-authored-by: Steven <steven@ceriously.com>
* Apply suggestions from code review
Co-authored-by: Steven <steven@ceriously.com>
Co-authored-by: Mark Glagola <mark.glagola@gmail.com>
Co-authored-by: Steven <steven@ceriously.com>
Follow up to #4897
* `vc link` - Update message to say `Set up ~/proj`
* `vc dev` - Update message to say `Set up and develop ~/proj`
* `vc link --help` - Updated example message to include `vc link ~/proj` usage
When pages are fully static and don't leverage preview mode or revalidation we can skip tracing the pages for generating the lambdas since lambdas aren't needed in this case
* [build-utils] Make `runPackageJsonScript()` run the `vercel-` or `now-` if defined in `package.json`
* [build-utils] Export `getScriptName()`
* [next] Use `getScriptName()` and `remove()`
* [node] Update for `vercel-`
* [static-build] Update for `vercel-`
* Remove debug
* Add `getScriptName()` unit tests
* Test for `vercel-build` in e2e
* Make platform name behavior be opt-in
So that it's not a breaking behavior change.
* Check for only "vercel-build" or "now-build", but not "build"
* Simplify `getScriptName()` to return the first existing script in a possible set
* Revert change
* Fix test
Co-authored-by: Joe Haddad <joe.haddad@zeit.co>
Co-authored-by: kodiakhq[bot] <49736102+kodiakhq[bot]@users.noreply.github.com>
Bumps [codecov](https://github.com/codecov/codecov-node) from 3.6.5 to 3.7.1.
<details>
<summary>Commits</summary>
<ul>
<li><a href="29dd5b6b03"><code>29dd5b6</code></a> 3.7.1</li>
<li><a href="c0711c6566"><code>c0711c6</code></a> Switch from execSync to execFileSync (<a href="https://github-redirect.dependabot.com/codecov/codecov-node/issues/180">#180</a>)</li>
<li><a href="5f6cc62d4f"><code>5f6cc62</code></a> Bump lodash from 4.17.15 to 4.17.19 (<a href="https://github-redirect.dependabot.com/codecov/codecov-node/issues/183">#183</a>)</li>
<li><a href="0c4d7f3c6f"><code>0c4d7f3</code></a> Merge pull request <a href="https://github-redirect.dependabot.com/codecov/codecov-node/issues/182">#182</a> from codecov/update-readme-badges</li>
<li><a href="cc5e121842"><code>cc5e121</code></a> Update depstat image and urls</li>
<li><a href="b44b44e1f8"><code>b44b44e</code></a> Update readme with 400 error info (<a href="https://github-redirect.dependabot.com/codecov/codecov-node/issues/181">#181</a>)</li>
<li><a href="bb79335719"><code>bb79335</code></a> V3.7.0 (<a href="https://github-redirect.dependabot.com/codecov/codecov-node/issues/179">#179</a>)</li>
<li><a href="0d7b9b01cb"><code>0d7b9b0</code></a> Remove <code>'x-amz-acl': 'public-read'</code> header (<a href="https://github-redirect.dependabot.com/codecov/codecov-node/issues/178">#178</a>)</li>
<li><a href="eeff4e1953"><code>eeff4e1</code></a> Bump acorn from 5.7.3 to 5.7.4 (<a href="https://github-redirect.dependabot.com/codecov/codecov-node/issues/174">#174</a>)</li>
<li><a href="eb8a527470"><code>eb8a527</code></a> Merge pull request <a href="https://github-redirect.dependabot.com/codecov/codecov-node/issues/172">#172</a> from RoboCafaz/bugfix/codebuild-pr-parser</li>
<li>Additional commits viewable in <a href="https://github.com/codecov/codecov-node/compare/v3.6.5...v3.7.1">compare view</a></li>
</ul>
</details>
<br />
[](https://help.github.com/articles/configuring-automated-security-fixes)
Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`.
[//]: # (dependabot-automerge-start)
[//]: # (dependabot-automerge-end)
---
<details>
<summary>Dependabot commands and options</summary>
<br />
You can trigger Dependabot actions by commenting on this PR:
- `@dependabot rebase` will rebase this PR
- `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it
- `@dependabot merge` will merge this PR after your CI passes on it
- `@dependabot squash and merge` will squash and merge this PR after your CI passes on it
- `@dependabot cancel merge` will cancel a previously requested merge and block automerging
- `@dependabot reopen` will reopen this PR if it is closed
- `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
- `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
- `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
- `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
- `@dependabot use these labels` will set the current labels as the default for future PRs for this repo and language
- `@dependabot use these reviewers` will set the current reviewers as the default for future PRs for this repo and language
- `@dependabot use these assignees` will set the current assignees as the default for future PRs for this repo and language
- `@dependabot use this milestone` will set the current milestone as the default for future PRs for this repo and language
You can disable automated security fix PRs for this repo from the [Security Alerts page](https://github.com/vercel/vercel/network/alerts).
</details>
Previously, users would have to run `vc env pull` to fetch cloud environment
variables into `.env`. After this PR, if no `.env` or `.build.env` file is present,
environment variables will be pulled by `vc dev` from your Vercel Environment
Variables settings, no file necessary.
This makes the updating logic be asynchronous instead of synchronous, and as such will make boot-up of CLI be faster.
The actual update notification display is identical to previous, we are not using `update-notifier`'s default boxen rendering.
Now that `@vercel/static-build` is being symlinked to CLI due to the
yarn workspace, `vc dev` will always use the latest code for
zero-config, so this "npm pack" logic is no longer necessary.
The `vercel.json` also no longer gets created in this test so that
zero-config is used.
Ensures that `VERCEL_REGION` is set for API calls when the runtime
implements `startDevServer()`.
Also adds `VERCEL_URL` which was previously not defined.
The Vercel proxy request headers (`x-vercel-deployment-url` for example)
were not being sent to the dev server when the Runtime defines
`startDevServer()`. This is now fixed.
Also updates the header names to match production:
- `now` -> `vercel`
- 'x-now-trace', 'x-now-id', and 'x-now-log-id' are removed
Fixes#4729.
CH-3242
When a user has project configuration in `.vercel` that corresponds to a team that they are not a part of, we currently throw a 403 error. This adds special handling so that we can show a specific message when this happens.
I didn't want to update the return type of `getProjectByIdOrName` because we only want to handle this 403 in a special case, so I `throw` it instead.
Other changes are linter.
This is for `@vercel/go` to work on Windows, which currently fails with
this error:
```
panic: write pipe: The handle is invalid.
goroutine 1 [running]:
main.main()
C:/Users/Nathan/Code/casca/vercel-go-test/.vercel/cache/go/2flefmhra8o/api/vercel-dev-server-main.go:25 +0x1ec
exit status 2
```
So this fallback writes the port number to a temp file that
`startDevServer()` polls for in order to figure out the port number.
This PR adds an optional property called `sort` to each framework so that we can change the order returned in the API.
The reason this is necessary is because the order of the original array determines the precedence of framework detection. So we need another way to indicate the order of templates/examples returned from the API.
In particular, we need "Next.js" to be first and "Other" to be last.
I also updated the deprecated `@now/node` usage to `@vercel/node` in the API.
* [@vercel/build-utils] Improve Nuxt build
Need review from @pi0 and @danielroe
* Update packages/now-static-build/src/frameworks.ts
Co-authored-by: Daniel Roe <daniel@roe.dev>
Co-authored-by: Daniel Roe <daniel@roe.dev>
Co-authored-by: Andy <AndyBitz@users.noreply.github.com>
This fixes dynamic routes missing inside of shared lambdas for non-revalidate pages that leverage preview mode which causes them to not be able to render. Additional tests have also been added to ensure preview mode is working properly
This adds failing page names to our tests which should be resolved once the correct regexes is being generated for the routes-manifest in Next.js
Co-authored-by: Joe Haddad <joe.haddad@zeit.co>
Co-authored-by: Steven <steven@ceriously.com>
When a user performs an action such as trying to add a domain they don't own, the API returns a 400-499 response code.
Previously, we would save this error in Sentry but this PR changes the behavior so that the error is printed locally for the user but not saved in Sentry.
This reverts commit f11eb32b2c.
Reverts PR #4816
This PR adds back the Blitz.js demo now that we confirmed the example works and is deployed to the correct account.
This is a re-introduction of #4697, which was reverted for performance
resons. But now that #4760 and #4793 have landed, we can enable this
behavior again.
The first version of `routeKeys` which was Array based could contain invalid named regexes which would break the build during route validation so this disables using them in that version of the manifest instead of trying to leverage them still. It also adds an additional test fixture with this version of the manifest to ensure it is still working properly
This adds [Blitz.js](https://github.com/blitz-js/blitz) to the zero-config frameworks.
Blitz compiles to a Next.js app, so it uses the same `@vercel/next` builder.
The change in `packages/now-build-utils/src/detect-builders.ts` was made according to @styfle's suggestion in Slack.
---
**This is a rerun of #4219 which had to be reverted because of this:**
> It looks like the @vercel/next package still requires next in the dependencies.
>
> When I've deployed the example I've got only a file listing, but when I added next to the dependencies it worked. I'll revert for now.
This new PR fixes that problem with a small refactor to `@vercel/next`.
`@vercel/next` was getting the Next version two different ways:
1. By checking project root package.json for `next` in deps or devDeps
2. By trying to resolve the installed next version and get `version` from its package.json
My refactor consolidates those two approaches by changing the existing `getNextVersion()` function to first try and resolve the real next version. If that fails, fall back to checking the project root.
Blitz bundles Next, so the real next package version should always be resolved.
The current code uses `getAllProjectFiles()` which globs for every file
in the project, not considering the `.vercelignore` file and default
ignore list. For example, every file in the `node_modules` directory is
selected, just for `vercel dev` to manually ignore them afterwards,
which is very slow and wasteful. For a simple Next.js project, this
globbing was taking over 3 seconds on my machine 🤯!
Solution is to use the `staticFiles()` function which is the same as
`vercel dev` uses at boot-up time. This function properly considers the
ignore list and thus is much faster, and the manual filtering is no
longer necessary by `vercel dev`. For the same simple Next.js project,
this function takes on average 10 milliseconds.
Also did a bit of cleanup and removed the `getAllProjectFiles()`
function since it is no longer used anywhere.
For `getServerSideProps` routes the non-named data route was being used for routes causing dynamic route params that were being trusted from the proxy to be incorrect. Our tests weren't failing after trusting the values from the proxy was landed in Next.js on canary due to the `21-server-props` test suite not running against the latest canary which is updated in this PR.
Note: the below Next.js PR is not needed or can be reverted if this PR is landed
x-ref: https://github.com/vercel/next.js/pull/14829
* [cli] Reduce number of times `getNowConfig()` is invoked in `vercel dev`
When using the `vercel dev` command, the `getNowConfig()` function was
being invoked many times per HTTP-request. It should only be read _once_
per HTTP request as it may be an expensive function depending on the
project size.
This change reduces the number of times the function is called to once
per HTTP request, and passes around the resulting `nowConfig` object to
the functions that require it.
* Fix default values
* Remove unnecessary type narrowing
* Remove one more `getNowConfig()` invocation
Co-authored-by: kodiakhq[bot] <49736102+kodiakhq[bot]@users.noreply.github.com>
This adds the Lockfile from Gatsby's official starter to fix deployments.
```
❯ npx gatsby-cli new ~/Desktop/scratch/test-default
❯ cp ~/Desktop/scratch/test-default/yarn.lock examples/gatsby
❯ cd examples/gatsby
❯ yarn
❯ git add examples/gatsby/yarn.lock
```
This fixes mapping dynamic routes to their shared lambdas failing from the `dynamicPageLambdaRoute` not being injected directly after the dynamic route due to dynamic routes now containing a `query` which caused the route lookup to fail.
This is resolved by making sure to parse the pathname while injecting the `dynamicPageLambdaRoute` so the route can be looked up correctly. This also adds additional test cases to prevent regressing on this along with updating existing fixtures for custom routes being de-experimentalized
This reverts commit ffb98781f1 (#4697),
because it was realized that `vc dev` reads this configuration file many
times per HTTP request, causing the server to feel extremely slow.
Reverting this optimization for now until the over-reading issue is
addressed.
This PR improves the error handling when a zero config framework has an unexpected output directory.
Previously, setting a Docusaurus 2.0 build command to `docusaurus build && mv build foo` would fail with the following:
```
Error: ENOENT: no such file or directory, scandir '/vercel/514ce14b/build'
```
With this PR, the error message will show the expected:
```
Error: No Output Directory named "build" found after the Build completed. You can configure the Output Directory in your project settings. Learn more: https://vercel.com/docs/v2/platform/frequently-asked-questions#missing-public-directory
```
I also changed the usage of [`promisify(fs)`](https://nodejs.org/docs/latest-v10.x/api/util.html#util_util_promisify_original) to [`fs.promises`](https://nodejs.org/docs/latest-v10.x/api/fs.html#fs_fs_promises_api) which is available in Node 10 or newer.
Lastly, I updated the test suite to check if the correct error message is returned for builds we expect to fail.
Previously, when a project has a specific "Output Directory" configured
in the project settings page, it was not being correctly considered when
using `vercel dev`.
The main fix here is passing in the full project settings object
(including the `outputDirectory`) to the `detectBuilders()` function.
Also cleaned up a few types and updated the error message that was
previously being rendered to use a short link.
Due to Go's peculiar package importing structure, there's unfortunately no way to _directly_ invoke a Go serverless file, so the approach for this `startDevServer()` function is:
* Create a temp directory in `.vercel/cache`
* Run the `analyze` Go program on the entrypoint file to determine the `functionName`
* Copy the entrypoint file into the temp directory, while modifying it to use `package main`
* Copy the `dev-server.go` file into the temp directory, replacing the placeholder function name with the `functionName` retrieved from the analysis step from before
* Execute `go run $tmp_dir` to spawn the Go HTTP server on an ephemeral port
* Return the Go process id and port number for `vercel dev` to proxy to
* After the Go process has exited, delete the temp directory
This adds more fine grained tests for our revalidate behavior to ensure pages are actually being updated instead of only checking the headers, it also corrects page lookups failing with shared lambdas enabled for dynamic pages using revalidate.
Closes: https://github.com/vercel/next.js/issues/14497
Since the filesystem watcher may be slow, it's actually faster and more
reliable to simply re-read the `vercel.json` configuration for every
HTTP request. This also simplifies the logic as an added benefit.
Some `sleep()` calls are removed from relevant tests that were
previously necessary due to the lag in the filesystem watcher.
This PR improves the validation error message when the user has an invalid `vercel.json` file.
Previously, the error message did not account for nested properties so `{"foo": "will error"}` looked fine because it would mention there is an additional property `foo`. However, the error message for `{ "routes": [{ "foo": "will error" }] }` did not mention anything about `routes` when it explaining there was an additional property `foo`. This became more apparent as we added nested properties for `rewrites` and `redirects` (see tests in this PR).
This PR also adds suggestions for common mistakes such as `src` vs `source`.
In the latest canary of Next.js pages are no longer nested under the `BUILD_ID` folder and instead are nested under a hash for the page bundle content. To prevent these tests from breaking too often from changes in canary this updates to locate the page bundle using the `buildManifest`. This also updates our latest SSG fixture to test against the latest canary to help ensure the feature doesn't break with a new canary release
Append `# Created by Vercel CLI` to the head of `.env` file and automatically overwrite the file if it's there next time without confirmation.
https://app.clubhouse.io/vercel/story/316
This PR fixes the error message when the client does not have internet connectivity or perhaps DNS is misconfigured such that the hostname cannot be resolved.
This PR fixes#4239 where using `vercel dev` to work on monorepos where
the Next.js app is not in the topmost directory fails to correctly route
to dynamic pages.
After investigating the devServer router, @styfle prompted me to
investigate the @vercel/next builder. He also suggested restricting
`check` to be false only when running in `now dev`.
Co-authored-by: Steven <steven@ceriously.com>
Bump node-file-trace to fix a webpack tracing bug that looks like the following:
```
TypeError: Cannot read property 'type' of null
at handleWrappers (/vercel/e77875438c1cd74b/.build-utils/.builder/node_modules/@vercel/next/dist/index.js:12763:58)
at module.exports.447.module.exports (/vercel/e77875438c1cd74b/.build-utils/.builder/node_modules/@vercel/next/dist/index.js:14674:3)
at Job.emitDependency (/vercel/e77875438c1cd74b/.build-utils/.builder/node_modules/@vercel/next/dist/index.js:11730:40)
at /vercel/e77875438c1cd74b/.build-utils/.builder/node_modules/@vercel/next/dist/index.js:11755:20
at async Promise.all (index 9)
at async Job.emitDependency (/vercel/e77875438c1cd74b/.build-utils/.builder/node_modules/@vercel/next/dist/index.js:11736:5)
at async Promise.all (index 1)
at async Object.module.exports.328.module.exports [as default] (/vercel/e77875438c1cd74b/.build-utils/.builder/node_modules/@vercel/next/dist/index.js:11514:3)
at async Object.module.exports.178.exports.build (/vercel/e77875438c1cd74b/.build-utils/.builder/node_modules/@vercel/next/dist/index.js:6076:69)
at async buildStep (/var/task/sandbox-worker.js:20407:20)
```
- [0.6.2](https://github.com/vercel/node-file-trace/releases/tag/0.6.2)
- [0.6.3](https://github.com/vercel/node-file-trace/releases/tag/0.6.3)
- [0.6.4](https://github.com/vercel/node-file-trace/releases/tag/0.6.4)
Depends on #4355
As mentioned by @dav-is we can prefix the outputs with the `basePath` instead of using a rewrite so that we make sure to 404 when the basePath isn't prefixed on the output. This behavior is also matched in Next.js with [this PR](https://github.com/zeit/next.js/pull/9988).
x-ref: https://github.com/zeit/now/pull/3478
This updates to leverage changes from https://github.com/zeit/next.js/pull/12801 which resolves invalid named regexes being used when the segments contain non-word characters e.g. `/[hello-world]`.
Failing page names have also been added to the `23-custom-routes-verbose` fixture. Since the routeKeys aren't applied for dynamic routes in this PR until the routes-manifest version is bumped in the latest canary of Next.js the added test cases will be passing now and should be re-run to ensure passing after a new canary of Next.js is released with the routes-manifest version bump
On Node 10, the `require.resolve()` with "paths" does not return the
proper value relative to the `node_modules` directory. To wit:
```
$ node -v
v10.16.3
$ node -p "require.resolve('typescript', { paths: [process.cwd()] })"
/Users/nrajlich/Code/vercel/vercel/packages/now-node/dist/typescript.js
$ node -v
v14.4.0
$ node -p "require.resolve('typescript', { paths: [process.cwd()] })"
/Users/nrajlich/Code/vercel/vercel/node_modules/typescript/lib/typescript.js
```
(**Note:** cwd when running these commands is the `dist` dir of `@vercel/node`)
So the solution is to just let `require.resolve()` throw an error so the
default string "typescript" is used instead of a resolved absolute path.
This PR adds a E2E CLI test to ensure that the Gatsby example deploys correctly and that the second deployment has the proper cached directories.
Co-authored-by: Nathan Rajlich <n@n8.io>
Co-authored-by: Andy <AndyBitz@users.noreply.github.com>
2020-06-12 16:51:55 -04:00
804 changed files with 130591 additions and 13081 deletions
The following page is a reference for how to create a Runtime using the available Runtime API.
The following page is a reference for how to create a Runtime by implementing
the Runtime API interface.
A Runtime is an npm module that exposes a `build` function and optionally an `analyze` function and `prepareCache` function.
Official Runtimes are published to [npmjs.com](https://npmjs.com) as a package and referenced in the `use` property of the `vercel.json` configuration file.
However, the `use` property will work with any [npm install argument](https://docs.npmjs.com/cli/install) such as a git repo url which is useful for testing your Runtime.
A Runtime is an npm module that implements the following interface:
The `version` property and the `build()` function are the only _required_ fields.
The rest are optional extensions that a Runtime _may_ implement in order to
enhance functionality. These functions are documented in more detail below.
Official Runtimes are published to [the npm registry](https://npmjs.com) as a package and referenced in the `use` property of the `vercel.json` configuration file.
> **Note:** The `use` property in the `builds` array will work with any [npm
> install argument](https://docs.npmjs.com/cli/install) such as a git repo URL,
> which is useful for testing your Runtime. Alternatively, the `functions` property
> requires that you specify a specifc tag published to npm, for stability purposes.
See the [Runtimes Documentation](https://vercel.com/docs/runtimes) to view example usage.
@@ -16,146 +39,170 @@ A **required** exported constant that decides which version of the Runtime API t
The latest and suggested version is `3`.
### `analyze`
**Example:**
An **optional** exported function that returns a unique fingerprint used for the purpose of [build de-duplication](https://vercel.com/docs/v2/platform/deployments#deduplication). If the `analyze` function is not supplied, a random fingerprint is assigned to each build.
```js
exportanalyze({
files:Files,
entrypoint:String,
workPath:String,
config:Object
}):Stringfingerprint
```typescript
exportconstversion=3;
```
If you are using TypeScript, you should use the following types:
### `build()`
```ts
import{AnalyzeOptions}from'@vercel/build-utils'
A **required** exported function that returns a Serverless Function.
exportanalyze(options: AnalyzeOptions){
return'fingerprint goes here'
> What's a Serverless Function? Read about [Serverless Functions](https://vercel.com/docs/v2/serverless-functions/introduction) to learn more.
// Create a mapping of file names and `File` object instances to cache here…
return{
output:{
'path-to-file':File,
'path-to-lambda':Lambda
},
watch:[],
routes:{}
}
'path-to-file':File,
};
}
```
### `prepareCache`
### `shouldServe()`
An **optional** exported function that is equivalent to [`build`](#build), but it executes the instructions necessary to prepare a cache for the next run.
An **optional** exported function that is only used by `vercel dev` in [Vercel
CLI](https://vercel.com/download) and indicates whether a
[Runtime](https://vercel.com/docs/runtimes) wants to be responsible for responding
to a certain request path.
```js
prepareCache({
files:Files,
entrypoint:String,
workPath:String,
cachePath:String,
config:Object
}):FilescacheOutput
```
**Example:**
If you are using TypeScript, you can import the types for each of these functions by using the following:
// Determine whether or not the Runtime should respond to the request path here…
exportprepareCache(options: PrepareCacheOptions){
return{'path-to-file':File}
returnoptions.requestPath===options.entrypoint;
}
```
### `shouldServe`
If this function is not defined, Vercel CLI will use the [default implementation](https://github.com/vercel/vercel/blob/52994bfe26c5f4f179bdb49783ee57ce19334631/packages/now-build-utils/src/should-serve.ts).
An **optional** exported function that is only used by `vercel dev` in [Vercel CLI](https:///download) and indicates whether a [Runtime](https://vercel.com/docs/runtimes) wants to be responsible for building a certain request path.
### `startDevServer()`
```js
shouldServe({
entrypoint:String,
files:Files,
config:Object,
requestPath:String,
workPath:String
}):Boolean
```
An **optional** exported function that is only used by `vercel dev` in [Vercel
CLI](https://vercel.com/download). If this function is defined, Vercel CLI will
**not** invoke the `build()` function, and instead invoke this function for every
HTTP request. It is an opportunity to provide an optimized development experience
rather than going through the entire `build()` process that is used in production.
If you are using TypeScript, you can import the types for each of these functions by using the following:
This function is invoked _once per HTTP request_and is expected to spawn a child
process which creates an HTTP server that will execute the entrypoint code when
an HTTP request is received. This child process is _single-serve_ (only used for
a single HTTP request). After the HTTP response is complete, `vercel dev` sends
// In this example, the child process will write the port number to FD 3…
constportPipe=child.stdio[3];
constchildPort=awaitnewPromise(resolve=>{
portPipe.setEncoding('utf8');
portPipe.once('data',data=>{
resolve(Number(data));
});
});
return{pid: child.pid,port: childPort};
}
```
If this method is not defined, Vercel CLI will default to [this function](https://github.com/vercel/vercel/blob/52994bfe26c5f4f179bdb49783ee57ce19334631/packages/now-build-utils/src/should-serve.ts).
### Runtime Options
The exported functions [`analyze`](#analyze), [`build`](#build), and [`prepareCache`](#preparecache) receive one argument with the following properties.
**Properties:**
-`files`: All source files of the project as a [Files](#files) data structure.
-`entrypoint`: Name of entrypoint file for this particular build job. Value `files[entrypoint]` is guaranteed to exist and be a valid [File](#files) reference. `entrypoint` is always a discrete file and never a glob, since globs are expanded into separate builds at deployment time.
-`workPath`: A writable temporary directory where you are encouraged to perform your build process. This directory will be populated with the restored cache from the previous run (if any) for [`analyze`](#analyze) and [`build`](#build).
-`cachePath`: A writable temporary directory where you can build a cache for the next run. This is only passed to `prepareCache`.
-`config`: An arbitrary object passed from by the user in the [Build definition](#defining-the-build-step) in `vercel.json`.
## Examples
Check out our [Node.js Runtime](https://github.com/vercel/vercel/tree/master/packages/now-node), [Go Runtime](https://github.com/vercel/vercel/tree/master/packages/now-go), [Python Runtime](https://github.com/vercel/vercel/tree/master/packages/now-python) or [Ruby Runtime](https://github.com/vercel/vercel/tree/master/packages/now-ruby) for examples of how to build one.
## Technical Details
### Execution Context
A [Serverless Function](https://vercel.com/docs/v2/serverless-functions/introduction) is created where the Runtime logic is executed. The lambda is run using the Node.js 8 runtime. A brand new sandbox is created for each deployment, for security reasons. The sandbox is cleaned up between executions to ensure no lingering temporary files are shared from build to build.
- Runtimes are executed in a Linux container that closely matches the Servereless Function runtime environment.
- The Runtime code is executed using Node.js version **12.x**.
- A brand new sandbox is created for each deployment, for security reasons.
- The sandbox is cleaned up between executions to ensure no lingering temporary files are shared from build to build.
All the APIs you export ([`analyze`](#analyze), [`build`](#build) and [`prepareCache`](#preparecache)) are not guaranteed to be run in the same process, but the filesystem we expose (e.g.: `workPath` and the results of calling [`getWriteableDirectory`](#getWriteableDirectory) ) is retained.
All the APIs you export ([`analyze()`](#analyze), [`build()`](#build),
[`prepareCache()`](#preparecache), etc.) are not guaranteed to be run in the
same process, but the filesystem we expose (e.g.: `workPath` and the results
of calling [`getWritableDirectory`](#getWritableDirectory) ) is retained.
If you need to share state between those steps, use the filesystem.
@@ -173,11 +220,11 @@ The env and secrets specified by the user as `build.env` are passed to the Runti
When you publish your Runtime to npm, make sure to not specify `@vercel/build-utils` (as seen below in the API definitions) as a dependency, but rather as part of `peerDependencies`.
## Types
## `@vercel/build-utils` Types
### `Files`
```ts
```typescript
import{File}from'@vercel/build-utils';
typeFiles={[filePath: string]:File};
```
@@ -188,7 +235,7 @@ When used as an input, the `Files` object will only contain `FileRefs`. When `Fi
An example of a valid output `Files` object is:
```json
```javascript
{
"index.html":FileRef,
"api/index.js":Lambda
@@ -199,7 +246,7 @@ An example of a valid output `Files` object is:
This is an abstract type that can be imported if you are using TypeScript.
```ts
```typescript
import{File}from'@vercel/build-utils';
```
@@ -211,71 +258,71 @@ Valid `File` types include:
### `FileRef`
```ts
```typescript
import{FileRef}from'@vercel/build-utils';
```
This is a [JavaScript class](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Classes) that represents an abstract file instance stored in our platform, based on the file identifier string (its checksum). When a `Files` object is passed as an input to `analyze` or `build`, all its values will be instances of `FileRef`.
This is a [class](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Classes) that represents an abstract file instance stored in our platform, based on the file identifier string (its checksum). When a `Files` object is passed as an input to `analyze` or `build`, all its values will be instances of `FileRef`.
**Properties:**
-`mode: Number` file mode
-`digest: String` a checksum that represents the file
-`mode: Number` file mode
-`digest: String` a checksum that represents the file
**Methods:**
-`toStream(): Stream` creates a [Stream](https://nodejs.org/api/stream.html) of the file body
-`toStream(): Stream` creates a [Stream](https://nodejs.org/api/stream.html) of the file body
### `FileFsRef`
```ts
```typescript
import{FileFsRef}from'@vercel/build-utils';
```
This is a [JavaScript class](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Classes) that represents an abstract instance of a file present in the filesystem that the build process is executing in.
This is a [class](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Classes) that represents an abstract instance of a file present in the filesystem that the build process is executing in.
**Properties:**
-`mode: Number` file mode
-`fsPath: String` the absolute path of the file in file system
-`mode: Number` file mode
-`fsPath: String` the absolute path of the file in file system
**Methods:**
-`static async fromStream({ mode: Number, stream: Stream, fsPath: String }): FileFsRef` creates an instance of a [FileFsRef](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object) from `Stream`, placing file at `fsPath` with `mode`
-`toStream(): Stream` creates a [Stream](https://nodejs.org/api/stream.html) of the file body
-`static async fromStream({ mode: Number, stream: Stream, fsPath: String }): FileFsRef` creates an instance of a [FileFsRef](#FileFsRef) from `Stream`, placing file at `fsPath` with `mode`
-`toStream(): Stream` creates a [Stream](https://nodejs.org/api/stream.html) of the file body
### `FileBlob`
```ts
```typescript
import{FileBlob}from'@vercel/build-utils';
```
This is a [JavaScript class](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Classes) that represents an abstract instance of a file present in memory.
This is a [class](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Classes) that represents an abstract instance of a file present in memory.
**Properties:**
-`mode: Number` file mode
-`data: String | Buffer` the body of the file
-`mode: Number` file mode
-`data: String | Buffer` the body of the file
**Methods:**
-`static async fromStream({ mode: Number, stream: Stream }):FileBlob` creates an instance of a [FileBlob](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object) from [`Stream`](https://nodejs.org/api/stream.html) with `mode`
-`toStream(): Stream` creates a [Stream](https://nodejs.org/api/stream.html) of the file body
-`static async fromStream({ mode: Number, stream: Stream }):FileBlob` creates an instance of a [FileBlob](#FileBlob) from [`Stream`](https://nodejs.org/api/stream.html) with `mode`
-`toStream(): Stream` creates a [Stream](https://nodejs.org/api/stream.html) of the file body
### `Lambda`
```ts
```typescript
import{Lambda}from'@vercel/build-utils';
```
This is a [JavaScript class](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Classes), called a Serverless Function, that can be created by supplying `files`, `handler`, `runtime`, and `environment` as an object to the [`createLambda`](#createlambda) helper. The instances of this class should not be created directly. Instead, invoke the [`createLambda`](#createlambda) helper function.
This is a [class](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Classes) that represents a Serverless Function. An instance can be created by supplying `files`, `handler`, `runtime`, and `environment` as an object to the [`createLambda`](#createlambda) helper. The instances of this class should not be created directly. Instead, invoke the [`createLambda`](#createlambda) helper function.
**Properties:**
-`files: Files` the internal filesystem of the lambda
-`handler: String` path to handler file and (optionally) a function name it exports
-`runtime: LambdaRuntime` the name of the lambda runtime
-`environment: Object` key-value map of handler-related (aside of those passed by user) environment variables
-`files: Files` the internal filesystem of the lambda
-`handler: String` path to handler file and (optionally) a function name it exports
-`runtime: LambdaRuntime` the name of the lambda runtime
-`environment: Object` key-value map of handler-related (aside of those passed by user) environment variables
### `LambdaRuntime`
@@ -291,15 +338,15 @@ This is an abstract enumeration type that is implemented by one of the following
-`ruby2.5`
-`provided`
## JavaScript API
## `@vercel/build-utils` Helper Functions
The following is exposed by `@vercel/build-utils` to simplify the process of writing Runtimes, manipulating the file system, using the above types, etc.
### `createLambda`
### `createLambda()`
Signature: `createLambda(Object spec): Lambda`
Signature: `createLambda(Object spec): Lambda`
```ts
```typescript
import{createLambda}from'@vercel/build-utils';
```
@@ -316,29 +363,33 @@ await createLambda({
});
```
### `download`
### `download()`
Signature: `download(): Files`
Signature: `download(): Files`
```ts
```typescript
import{download}from'@vercel/build-utils';
```
This utility allows you to download the contents of a [`Files`](#files) data structure, therefore creating the filesystem represented in it.
This utility allows you to download the contents of a [`Files`](#files) data
structure, therefore creating the filesystem represented in it.
Since `Files` is an abstract way of representing files, you can think of`download` as a way of making that virtual filesystem _real_.
Since `Files` is an abstract way of representing files, you can think of
`download()` as a way of making that virtual filesystem _real_.
If the **optional**`meta` property is passed (the argument for [build](#build)), only the files that have changed are downloaded. This is decided using `filesRemoved` and `filesChanged` inside that object.
If the **optional**`meta` property is passed (the argument for
[`build()`](#build)), only the files that have changed are downloaded.
This is decided using `filesRemoved` and `filesChanged` inside that object.
The domain you supplied cannot be verified using either the intended set of nameservers or the given verification TXT record.
The domain you supplied cannot be verified using the intended nameservers.
#### Possible Ways to Fix It
#### Possible Way to Fix It
Apply the intended set of nameservers to your domain or add the given TXT verification record through your domain provider.
Apply the intended set of nameservers to your domain.
You can retrieve both the intended nameservers and TXT verification record for the domain you wish to verify by running `vercel domains inspect <domain>`.
When you have added either verification method to your domain, you can run `vercel domains verify <domain>` again to complete verification for your domain.
Vercel will also automatically check periodically that your domain has been verified and automatically mark it as such if we detect either verification method on the domain.
If you would not like to verify your domain, you can remove it from your account using `vercel domains rm <domain>`.
This directory is a brief example of a [Blitz.js](https://blitzjs.com/) project that can be deployed with Vercel and zero configuration.
## Deploy Your Own
Deploy your own Blitz.js project with Vercel by viewing the [documentation on deploying to Vercel](https://blitzjs.com/docs/deploy-vercel)
[](https://vercel.com/import/project?template=https://github.com/vercel/vercel/tree/master/examples/blitzjs)
### How We Created This Example
To get started with Blitz.js, you can use [npx](https://www.npmjs.com/package/npx) to initialize the project:
@@ -19,11 +19,3 @@ To get started with React, along with [Serverless Functions](https://vercel.com/
```shell
$ npx create-react-app my-app
```
### Deploying From Your Terminal
You can deploy your new React project, along with [Serverless Functions](https://vercel.com/docs/v2/serverless-functions/introduction), with a single command from your terminal using [Vercel CLI](https://vercel.com/download):
@@ -19,11 +19,3 @@ To get started with Gatsby on Vercel, you can use the [Gatsby CLI](https://www.g
```shell
$ gatsby new gatsby-site
```
### Deploying From Your Terminal
You can deploy your new Gatsby project, along with [Serverless Functions](https://vercel.com/docs/v2/serverless-functions/introduction), with a single command from your terminal using [Vercel CLI](https://vercel.com/download):
This is a [Next.js](https://nextjs.org/) project bootstrapped with [`create-next-app`](https://github.com/zeit/next.js/tree/canary/packages/create-next-app).
This is a [Next.js](https://nextjs.org/) project bootstrapped with [`create-next-app`](https://github.com/vercel/next.js/tree/canary/packages/create-next-app).
## Getting Started
@@ -21,7 +21,7 @@ To learn more about Next.js, take a look at the following resources:
- [Next.js Documentation](https://nextjs.org/docs) - learn about Next.js features and API.
- [Learn Next.js](https://nextjs.org/learn) - an interactive Next.js tutorial.
You can check out [the Next.js GitHub repository](https://github.com/zeit/next.js) - your feedback and contributions are welcome!
You can check out [the Next.js GitHub repository](https://github.com/vercel/next.js/) - your feedback and contributions are welcome!
This directory is a brief example of a [RedwoodJS](https://redwoodjs.com) app with [Serverless Functions](https://vercel.com/docs/v2/serverless-functions/introduction) that can be deployed with Vercel and zero configuration.
## Deploy Your Own
Deploy your own RedwoodJS project, along with Serverless Functions, with Vercel.
[](https://vercel.com/import/project?template=https://github.com/vercel/vercel/tree/master/examples/redwoodjs)
To get started with RedwoodJS on Vercel, you can [use Yarn to initialize](https://redwoodjs.com/tutorial/installation-starting-development) the project:
Use this folder to add static files directly to your app. All included files and folders will be copied directly into the `/dist` folder (created when Webpack builds for production). They will also be available during development when you run `yarn rw dev`.
>Note: files will *not* hot reload while the development server is running. You'll need to manually stop/start to access file changes.
### Example Use
A file like `favicon.png` will be copied to `/dist/favicon.png`. A folder containing a file such as `static-files/my-logo.jpg` will be copied to `/dist/static-files/my-logo.jpg`. These can be referenced in your code directly without any special handling, e.g.
Behind the scenes, we are using Webpack's ["copy-webpack-plugin"](https://github.com/webpack-contrib/copy-webpack-plugin).
## Best Practices
Because assets in this folder are bypassing the javascript module system, **this folder should be used sparingly** for assets such as favicons, robots.txt, manifests, libraries incompatible with Webpack, etc.
In general, it's best to import files directly into a template, page, or component. This allows Webpack to include that file in the bundle, which ensures Webpack will correctly process and move assets into the distribution folder, providing error checks and correct paths along the way.
### Example Asset Import with Webpack
Instead of handling our logo image as a static file per the example above, we can do the following:
```
import React from "react"
import logo from "./my-logo.jpg"
function Header() {
return <img src={logo} alt="Logo" />
}
export default Header
```
Behind the scenes, we are using Webpack's ["file-loader"](https://webpack.js.org/loaders/file-loader/) and ["url-loader](https://webpack.js.org/loaders/url-loader/) (for files smaller than 10kb).
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.