-
Notifications
You must be signed in to change notification settings - Fork 2.1k
use enableDevMode() or development condition instead of NODE_ENV
#4464
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
thanks @JoviDeCroock! (not sure what I did wrong before)
use latest dev mode with dual build (see graphql/graphql-js#4464) removes need for babel or swc
use just config setting: testEnvironment / customExportConditions use latest dev mode with dual build (see graphql/graphql-js#4464) no need for additional transformer
use just config setting: testEnvironment / customExportConditions use latest dev mode with dual build (see graphql/graphql-js#4464) no need for additional transformer
use just config setting: testEnvironment / customExportConditions use latest dev mode with dual build (see graphql/graphql-js#4464) no need for additional transformer
- use jest config setting: testEnvironment / customExportConditions - use latest dev mode with dual build (see graphql/graphql-js#4464) - no need for additional transformer
|
updated integration tests thanks to @JoviDeCroock offline help, jest test working (demonstrated also at: apollographql/apollo-server#8137) in terms of allowing switching back to prod mode, I still cannot reverse performance degradation in offline benchmarking even after 100,000 invocations of prod function, so will leave this simply as |
…graphql#4464) Motivation: This PR makes our build product cross-platform by dropping all Node.js specific code. In development mode, GraphQL.JS can provide an additional runtime check appropriate for development-time errors: the erroneous inclusion of multiple GraphQL.JS modules. Unlike earlier versions of GraphQL.JS, by default, development mode is disabled. This is to best ensure that production builds do not incur the performance and bundle size penalties associated with the additional checks. Also, unlike earlier versions, development mode is not configured by use of environment variables, which are accessed in disparate ways on the various platforms. In particular, the `NODE_ENV` environment variable now has no effect on triggering development mode. Rather, development mode is either enabled: 1. by setting a 'development' condition, which is possible only on platforms that support `package.json` conditional exports and custom conditions, or 2. by calling `enableDevMode()` within user code. Conditional exports with custom conditions are supported by: Node.js, Deno, Bun, Webpack 5, Rspack, Rollup (via the `node-resolve` plugin), esbuild, Vite, and Rsbuild. create-react-app and Next.js support conditional exports when using Webpack 5 as their bundler. Conditional exports with custom conditions are not supported by Webpack 4, Rollup (without the `node-resolve` plugin), older versions of Deno or transpilers such as swc. create-react-app and Next.js do not support conditional exports with custom conditions when using Webpack 4 as their bundler, nor does Next.js yet support conditional exports with custom conditions when using Turbopack (see vercel/next.js#78912). Testing frameworks such as Mocha, Jest, and Vitest support conditional exports with custom conditions, Integration tests within the repository demonstrate how to enable development mode using the `development` condition on various platforms that support this, as well as enabling development mode by calling `enableDevMode()` within user code. We encourage enabling development mode in a development environment. This facilitates the additional check to ensure that only a single GraphQL.JS module is used. Additional development-time checks may also be added in the future.
…graphql#4464) Motivation: This PR makes our build product cross-platform by dropping all Node.js specific code. In development mode, GraphQL.JS can provide an additional runtime check appropriate for development-time errors: the erroneous inclusion of multiple GraphQL.JS modules. Unlike earlier versions of GraphQL.JS, by default, development mode is disabled. This is to best ensure that production builds do not incur the performance and bundle size penalties associated with the additional checks. Also, unlike earlier versions, development mode is not configured by use of environment variables, which are accessed in disparate ways on the various platforms. In particular, the `NODE_ENV` environment variable now has no effect on triggering development mode. Rather, development mode is either enabled: 1. by setting a 'development' condition, which is possible only on platforms that support `package.json` conditional exports and custom conditions, or 2. by calling `enableDevMode()` within user code. Conditional exports with custom conditions are supported by: Node.js, Deno, Bun, Webpack 5, Rspack, Rollup (via the `node-resolve` plugin), esbuild, Vite, and Rsbuild. create-react-app and Next.js support conditional exports when using Webpack 5 as their bundler. Conditional exports with custom conditions are not supported by Webpack 4, Rollup (without the `node-resolve` plugin), older versions of Deno or transpilers such as swc. create-react-app and Next.js do not support conditional exports with custom conditions when using Webpack 4 as their bundler, nor does Next.js yet support conditional exports with custom conditions when using Turbopack (see vercel/next.js#78912). Testing frameworks such as Mocha, Jest, and Vitest support conditional exports with custom conditions, Integration tests within the repository demonstrate how to enable development mode using the `development` condition on various platforms that support this, as well as enabling development mode by calling `enableDevMode()` within user code. We encourage enabling development mode in a development environment. This facilitates the additional check to ensure that only a single GraphQL.JS module is used. Additional development-time checks may also be added in the future.
…graphql#4464) Motivation: This PR makes our build product cross-platform by dropping all Node.js specific code. In development mode, GraphQL.JS can provide an additional runtime check appropriate for development-time errors: the erroneous inclusion of multiple GraphQL.JS modules. Unlike earlier versions of GraphQL.JS, by default, development mode is disabled. This is to best ensure that production builds do not incur the performance and bundle size penalties associated with the additional checks. Also, unlike earlier versions, development mode is not configured by use of environment variables, which are accessed in disparate ways on the various platforms. In particular, the `NODE_ENV` environment variable now has no effect on triggering development mode. Rather, development mode is either enabled: 1. by setting a 'development' condition, which is possible only on platforms that support `package.json` conditional exports and custom conditions, or 2. by calling `enableDevMode()` within user code. Conditional exports with custom conditions are supported by: Node.js, Deno, Bun, Webpack 5, Rspack, Rollup (via the `node-resolve` plugin), esbuild, Vite, and Rsbuild. create-react-app and Next.js support conditional exports when using Webpack 5 as their bundler. Conditional exports with custom conditions are not supported by Webpack 4, Rollup (without the `node-resolve` plugin), older versions of Deno or transpilers such as swc. create-react-app and Next.js do not support conditional exports with custom conditions when using Webpack 4 as their bundler, nor does Next.js yet support conditional exports with custom conditions when using Turbopack (see vercel/next.js#78912). Testing frameworks such as Mocha, Jest, and Vitest support conditional exports with custom conditions, Integration tests within the repository demonstrate how to enable development mode using the `development` condition on various platforms that support this, as well as enabling development mode by calling `enableDevMode()` within user code. We encourage enabling development mode in a development environment. This facilitates the additional check to ensure that only a single GraphQL.JS module is used. Additional development-time checks may also be added in the future.
…graphql#4464) Motivation: This PR makes our build product cross-platform by dropping all Node.js specific code. In development mode, GraphQL.JS can provide an additional runtime check appropriate for development-time errors: the erroneous inclusion of multiple GraphQL.JS modules. Unlike earlier versions of GraphQL.JS, by default, development mode is disabled. This is to best ensure that production builds do not incur the performance and bundle size penalties associated with the additional checks. Also, unlike earlier versions, development mode is not configured by use of environment variables, which are accessed in disparate ways on the various platforms. In particular, the `NODE_ENV` environment variable now has no effect on triggering development mode. Rather, development mode is either enabled: 1. by setting a 'development' condition, which is possible only on platforms that support `package.json` conditional exports and custom conditions, or 2. by calling `enableDevMode()` within user code. Conditional exports with custom conditions are supported by: Node.js, Deno, Bun, Webpack 5, Rspack, Rollup (via the `node-resolve` plugin), esbuild, Vite, and Rsbuild. create-react-app and Next.js support conditional exports when using Webpack 5 as their bundler. Conditional exports with custom conditions are not supported by Webpack 4, Rollup (without the `node-resolve` plugin), older versions of Deno or transpilers such as swc. create-react-app and Next.js do not support conditional exports with custom conditions when using Webpack 4 as their bundler, nor does Next.js yet support conditional exports with custom conditions when using Turbopack (see vercel/next.js#78912). Testing frameworks such as Mocha, Jest, and Vitest support conditional exports with custom conditions, Integration tests within the repository demonstrate how to enable development mode using the `development` condition on various platforms that support this, as well as enabling development mode by calling `enableDevMode()` within user code. We encourage enabling development mode in a development environment. This facilitates the additional check to ensure that only a single GraphQL.JS module is used. Additional development-time checks may also be added in the future.
extracted from / based on:
Motivation:
This makes our build product cross-platform by dropping all Node.js specific code.
Differences:
import 'graphql/dev'to enable development mode on platforms that do not support setting custom conditions, while this PR uses:import { enableDevMode } from 'graphql'; enableDevMode()From the docs included in this PR: