@modern-js/module-tools-docs 2.25.2-beta.0 → 2.25.2

package/doc_build/static/search_index.en.8cd54797.json

@@ -1 +0,0 @@
-[{"id":0,"title":"buildConfig","routePath":"/module-tools/en/api/config/build-config","lang":"en","toc":[{"text":"alias","id":"alias","depth":2,"charIndex":400},{"text":"asset","id":"asset","depth":2,"charIndex":1412},{"text":"asset.path","id":"assetpath","depth":2,"charIndex":1471},{"text":"asset.limit","id":"assetlimit","depth":2,"charIndex":1575},{"text":"asset.publicPath","id":"assetpublicpath","depth":2,"charIndex":2137},{"text":"asset.svgr","id":"assetsvgr","depth":2,"charIndex":2425},{"text":"asset.svgr.include","id":"assetsvgrinclude","depth":2,"charIndex":3044},{"text":"asset.svgr.exclude","id":"assetsvgrexclude","depth":2,"charIndex":3162},{"text":"autoExternal","id":"autoexternal","depth":2,"charIndex":3279},{"text":"autoExternal.dependencies","id":"autoexternaldependencies","depth":2,"charIndex":4010},{"text":"autoExternal.peerDependencies","id":"autoexternalpeerdependencies","depth":2,"charIndex":4146},{"text":"buildType","id":"buildtype","depth":2,"charIndex":4277},{"text":"copy","id":"copy","depth":2,"charIndex":4435},{"text":"copy.patterns","id":"copypatterns","depth":2,"charIndex":4700},{"text":"copy.options","id":"copyoptions","depth":2,"charIndex":4873},{"text":"define","id":"define","depth":2,"charIndex":5170},{"text":"dts","id":"dts","depth":2,"charIndex":5873},{"text":"dts.abortOnError","id":"dtsabortonerror","depth":2,"charIndex":6090},{"text":"dts.distPath","id":"dtsdistpath","depth":2,"charIndex":6675},{"text":"dts.only","id":"dtsonly","depth":2,"charIndex":6779},{"text":"dts.respectExternal","id":"dtsrespectexternal","depth":2,"charIndex":6866},{"text":"dts.tsconfigPath","id":"dtstsconfigpath","depth":2,"charIndex":7296},{"text":"esbuildOptions","id":"esbuildoptions","depth":2,"charIndex":7389},{"text":"externalHelpers","id":"externalhelpers","depth":2,"charIndex":8564},{"text":"externals","id":"externals","depth":2,"charIndex":9565},{"text":"format","id":"format","depth":2,"charIndex":9901},{"text":"format: \\'esm\\'","id":"format:-\\'esm\\'","depth":3,"charIndex":-1},{"text":"format: \\'cjs\\'","id":"format:-\\'cjs\\'","depth":3,"charIndex":-1},{"text":"format: \\'iife\\'","id":"format:-\\'iife\\'","depth":3,"charIndex":-1},{"text":"format: \\'umd\\'","id":"format:-\\'umd\\'","depth":3,"charIndex":-1},{"text":"input","id":"input","depth":2,"charIndex":11330},{"text":"jsx","id":"jsx","depth":2,"charIndex":12045},{"text":"metafile","id":"metafile","depth":2,"charIndex":12550},{"text":"minify","id":"minify","depth":2,"charIndex":13080},{"text":"outDir","id":"outdir","depth":2,"charIndex":13341},{"text":"platform","id":"platform","depth":2,"charIndex":13430},{"text":"redirect","id":"redirect","depth":2,"charIndex":13623},{"text":"sideEffects","id":"sideeffects","depth":2,"charIndex":14323},{"text":"sourceDir","id":"sourcedir","depth":2,"charIndex":15419},{"text":"sourceMap","id":"sourcemap","depth":2,"charIndex":15653},{"text":"sourceType","id":"sourcetype","depth":2,"charIndex":15764},{"text":"splitting","id":"splitting","depth":2,"charIndex":15991},{"text":"style","id":"style","depth":2,"charIndex":16074},{"text":"style.less","id":"styleless","depth":2,"charIndex":16122},{"text":"style.less.lessOptions","id":"stylelesslessoptions","depth":2,"charIndex":16164},{"text":"style.less.additionalData","id":"stylelessadditionaldata","depth":2,"charIndex":16289},{"text":"style.less.implementation","id":"stylelessimplementation","depth":2,"charIndex":16544},{"text":"style.sass","id":"stylesass","depth":2,"charIndex":17149},{"text":"style.sass.sassOptions","id":"stylesasssassoptions","depth":2,"charIndex":17192},{"text":"style.sass.additionalData","id":"stylesassadditionaldata","depth":2,"charIndex":17298},{"text":"style.sass.implementation","id":"stylesassimplementation","depth":2,"charIndex":17613},{"text":"style.postcss","id":"stylepostcss","depth":2,"charIndex":18213},{"text":"style.inject","id":"styleinject","depth":2,"charIndex":18456},{"text":"style.autoModules","id":"styleautomodules","depth":2,"charIndex":19916},{"text":"style.modules","id":"stylemodules","depth":2,"charIndex":20263},{"text":"style.tailwindcss","id":"styletailwindcss","depth":2,"charIndex":20723},{"text":"target","id":"target","depth":2,"charIndex":21518},{"text":"transformImport","id":"transformimport","depth":2,"charIndex":22105},{"text":"Notes","id":"notes","depth":3,"charIndex":22559},{"text":"umdGlobals","id":"umdglobals","depth":2,"charIndex":22605},{"text":"umdModuleName","id":"umdmodulename","depth":2,"charIndex":23035}],"domain":"","content":"#\n\nbuildConfig is a configuration option that describes how to compile and generate\nbuild artifacts. It contains all the configurations related to the build\nprocess.\n\n * Type: object | object[]\n * Default: undefined\n\nTIP\n\nBefore start using buildConfig, please read the following documentation to\nunderstand its purpose:\n\n * Modifying Output Artifacts\n * In-Depth Understanding of the Build Process\n\n\nalias#\n\n * Type: Record | Function\n * Default: {'@': 'src',}\n\nTIP\n\nFor TypeScript projects, you only need to configure compilerOptions.paths in\ntsconfig.json, Module Tools will automatically recognize the alias in\ntsconfig.json, so there is no need to configure the alias field additionally.\n\nexport default {\n  buildConfig: {\n    alias: {\n      '@common': '. /src/common',\n    },\n  },\n};\n\n\nAfter the above configuration is done, if @common/Foo.tsx is referenced in the\ncode, it will map to the /src/common/Foo.tsx path.\n\nWhen the value of alias is defined as a function, you can accept the pre-defined\nalias object and modify it.\n\nexport default {\n  buildConfig: {\n    alias: alias => {\n      alias['@common'] = '. /src/common';\n    },\n  },\n};\n\n\nIt is also possible to return a new object as the final result in the function,\nwhich will override the pre-defined alias object.\n\nexport default {\n  buildConfig: {\n    alias: alias => {\n      return {\n        '@common': '. /src/common',\n      };\n    },\n  },\n};\n\n\n\nasset#\n\nContains configuration related to static assets.\n\n\nasset.path#\n\nStatic resource output path, will be based on outDir\n\n * Type: string\n * Default: assets\n\n\nasset.limit#\n\nUsed to set the threshold for static assets to be automatically inlined as\nbase64.\n\nBy default, Module Tools will inline assets such as images, fonts and media\nsmaller than 10KB during bundling. They are Base64 encoded and inlined in the\nbundles, eliminating the need for separate HTTP requests.\n\nYou can adjust this threshold by modifying the limit config.\n\n * Type: number\n * Default: 10 * 1024\n\nFor example, set limit to 0 to avoid assets inlining:\n\nexport default defineConfig({\n  buildConfig: {\n    asset: {\n      limit: 0,\n    },\n  },\n});\n\n\n\nasset.publicPath#\n\nThe CDN prefix given to unlinked resources when packaging\n\n * Type: string\n * Default: undefined\n\nexport default {\n  buildConfig: {\n    asset: {\n      publicPath: 'https://xxx/',\n    },\n  },\n};\n\n\nAt this point, all static resources will be prefixed with https://xxx/\n\n\nasset.svgr#\n\nPackaged to handle svg as a React component, options reference svgr, plus\nsupport for two configuration items include and exclude to match the svg file to\nbe handled\n\n * Type: boolean | object\n * Default: false\n\nWhen svgr feature is enabled, you can use svg as a component using the default\nexport.\n\n// true\n\n\nexport default () => ;\n\n\nWARNING\n\nThe following usage is not currently supported:\n\n\n\n\nWhen enabled, the type of svg used can be modified by adding a type definition\nto the modern-app-env.d.ts file:\n\ndeclare module '*.svg' {\n  const src: React.FunctionComponent>;\n  export default src;\n}\n\n/// \n\n\n\nasset.svgr.include#\n\nSet the matching svg file\n\n * Type: string | RegExp | (string | RegExp)[]\n * Default: /\\.svg$/\n\n\nasset.svgr.exclude#\n\nSet unmatched svg files\n\n * Type: string | RegExp | (string | RegExp)[]\n * Default: undefined\n\n\nautoExternal#\n\nAutomatically externalize project dependencies and peerDependencies and not\npackage them into the final bundle\n\n * Type: boolean | object\n * Default: true\n\nWhen we want to turn off the default handling behavior for third-party\ndependencies, we can do so by:\n\nexport default defineConfig({\n  buildConfig: {\n    autoExternal: false,\n  },\n});\n\n\nThis way the dependencies under \"dependencies\" and \"peerDependencies\" will be\npackaged. If you want to turn off the processing of only one of these\ndependencies, you can use the buildConfig.autoExternal in the form of an object.\n\nexport default defineConfig({\n  buildConfig: {\n    autoExternal: {\n      dependencies: false,\n      peerDependencies: false,\n    },\n  },\n});\n\n\n\nautoExternal.dependencies#\n\nWhether or not the dep dependencies of the external project are needed\n\n * Type: boolean\n * Default: true\n\n\nautoExternal.peerDependencies#\n\nWhether to require peerDep dependencies for external projects\n\n * Type: boolean\n * Default: true\n\n\nbuildType#\n\nThe build type, bundle will package your code, bundleless will only do the code\nconversion\n\n * Type: 'bundle' | 'bundleless'\n * Default: bundle\n\n\ncopy#\n\nCopies the specified file or directory into the build output directory\n\n * Type: object[]\n * Default: []\n\nexport default {\n  buildConfig: {\n    copy: [{ from: '. /src/assets', to: '' }],\n  },\n};\n\n\nReference for array settings: copy-webpack-plugin patterns\n\n\ncopy.patterns#\n\n * Type: CopyPattern[]\n * Default: []\n\ninterface CopyPattern {\n  from: string;\n  to?: string;\n  context?: string;\n  globOptions?: globby.GlobbyOptions;\n}\n\n\n\ncopy.options#\n\n * Type:\n\ntype Options = {\n  concurrency?: number;\n  enableCopySync?: boolean;\n};\n\n\n * Default: { concurrency: 100, enableCopySync: false }\n\n * concurrency: Specifies how many copy tasks to execute in parallel.\n\n * enableCopySync: Uses fs.copySync by default, instead of fs.copy.\n\n\ndefine#\n\nDefine global variables that will be injected into the code\n\n * Type: Record\n * Default: {}\n\nSince the define function is implemented by global text replacement, you need to\nensure that the global variable values are strings. A safer approach is to\nconvert the value of each global variable to a string, using JSON.stringify, as\nfollows.\n\nexport default {\n  buildConfig: {\n    define: {\n      VERSION: JSON.stringify('1.0'),\n    },\n  },\n};\n\n\nTIP\n\nTo prevent excessive global replacement substitution, it is recommended that the\nfollowing two principles be followed when using\n\n * Use upper case for global constants\n * Customize the prefix and suffix of global constants to ensure uniqueness\n\n\ndts#\n\nThe dts file generates the relevant configuration, by default it generates.\n\n * Type: false | object\n * Default:\n\n{\n  abortOnError: true,\n  distPath: './',\n  only: false,\n  tsconfigPath: './tsconfig.json',\n}\n\n\n\ndts.abortOnError#\n\nWhether to allow the build to succeed if a type error occurs.\n\n * Type: boolean\n * Default: true\n\nBy default, type errors will cause the build to fail. When abortOnError is set\nto false, the build will still succeed even if there are type issues in the\ncode:\n\nexport default defineConfig({\n  buildConfig: {\n    dts: {\n      abortOnError: false,\n    },\n  },\n});\n\n\nWARNING\n\nWhen this configuration is disabled, there is no guarantee that the type files\nwill be generated correctly. In buildType: 'bundle', which is the bundle mode,\ntype files will not be generated.\n\n\ndts.distPath#\n\nThe output path of the dts file, based on outDir\n\n * Type: string\n * Default: . /types\n\n\ndts.only#\n\nGenerate only dts files, not js files\n\n * Type: boolean\n * Default: false\n\n\ndts.respectExternal#\n\nWhen set to false, the type of third-party packages will be excluded from the\nbundle, when set to true, it will determine whether third-party types need to be\nbundled based on externals.\n\nWhen bundle d.ts, export is not analyzed, so any third-party package type you\nuse may break your build, which is obviously uncontrollable. So we can avoid it\nwith this configuration.\n\n * Type: boolean\n * Default: true\n\n\ndts.tsconfigPath#\n\nPath to the tsconfig file\n\n * Type: string\n * Default: . /tsconfig.json\n\n\nesbuildOptions#\n\nDirectly modify esbuild configuration\n\n * Type: Function\n * Default: c => c\n\nFor example, if we need to modify the file extension of the generated files:\n\nexport default defineConfig({\n  buildConfig: {\n    esbuildOptions: options => {\n      options.outExtension = { '.js': '.mjs' };\n      return options;\n    },\n  },\n});\n\n\nTIP\n\nWe have done many extensions based on the original esbuild build. Therefore,\nwhen using this configuration, pay attention to the following:\n\n 1. Prefer to use the configuration we provide. For example, esbuild does not\n    support target: 'es5', but we support this scenario internally using swc.\n    Setting target: 'es5' through esbuildOptions will result in an error.\n 2. Currently, we use enhanced-resolve internally to replace esbuild's resolve\n    algorithm, so modifying esbuild resolve-related configurations is invalid.\n    We plan to switch back in the future.\n 3. When using esbuild plugins, you need to add the plugins to the beginning of\n    the plugins array because we also intervene in the entire build process\n    through an esbuild plugin internally. Therefore, custom plugins need to be\n    registered first.\n\n\nexternalHelpers#\n\nBy default, the output JS code may depend on helper functions to support the\ntarget environment or output format, and these helper functions will be inlined\nin the file that requires it.\n\nWhen using SWC Transform for code transformation, you can enable the\nexternalHelpers configuration to convert inline helper functions to import them\nfrom the external module @swc/helpers.\n\n * Type: boolean\n * Default: false\n\nBelow is a comparison of the product changes before and after using this\nconfiguration.\n\nBefore enable:\n\n// helper function\nfunction asyncGeneratorStep(gen, resolve, reject, _next, _throw, key, arg) {\n  // ...\n}\n// helper function\nfunction _async_to_generator(fn) {\n  return function () {\n    // use asyncGeneratorStep\n    // ...\n  };\n}\n\n// your code\nexport var yourCode = function () {\n  // use _async_to_generator\n};\n\n\nAfter enabled:\n\n// helper functions imported from @swc/helpers\n\n\n// your code\nexport var yourCode = function () {\n  // use _async_to_generator\n};\n\n\n\nexternals#\n\nConfigure external dependencies that will not be packaged into the final bundle\n\n * Type:\n\ntype External = (string | RegExp)[];\n\n\n * Default: []\n * Build Type: Only supported for buildType: 'bundle'\n * Example:\n\nexport default defineConfig({\n  buildConfig: {\n    // do not bundle React\n    externals: ['react'],\n  },\n});\n\n\n\nformat#\n\nUsed to set the output format of JavaScript files. The options iife and umd only\ntake effect when buildType is bundle.\n\n * Type: 'esm' | 'cjs' | 'iife' | 'umd'\n * Default: cjs\n\n\nformat: 'esm'#\n\nesm stands for \"ECMAScript module\" and requires the runtime environment to\nsupport import and export syntax.\n\n * Example:\n\nexport default defineConfig({\n  buildConfig: {\n    format: 'esm',\n  },\n});\n\n\n\nformat: 'cjs'#\n\ncjs stands for \"CommonJS\" and requires the runtime environment to support\nexports, require, and module syntax. This format is commonly used in Node.js\nenvironments.\n\n * Example:\n\nexport default defineConfig({\n  buildConfig: {\n    format: 'cjs',\n  },\n});\n\n\n\nformat: 'iife'#\n\niife stands for \"immediately-invoked function expression\" and wraps the code in\na function expression to ensure that any variables in the code do not\naccidentally conflict with variables in the global scope. This format is\ncommonly used in browser environments.\n\n * Example:\n\nexport default defineConfig({\n  buildConfig: {\n    format: 'iife',\n  },\n});\n\n\n\nformat: 'umd'#\n\numd stands for \"Universal Module Definition\" and is used to run modules in\ndifferent environments such as browsers and Node.js. Modules in UMD format can\nbe used in various environments, either as global variables or loaded as modules\nusing module loaders like RequireJS.\n\n * Example:\n\nexport default defineConfig({\n  buildConfig: {\n    format: 'umd',\n  },\n});\n\n\n\ninput#\n\nSpecify the entry file for the build, in the form of an array that can specify\nthe directory\n\n * Type:\n\ntype Input =\n  | string[];\n  | {\n      [name: string]: string;\n    }\n\n\n * Default: ['src/index.ts'] in bundle mode, ['src'] in bundleless mode\n\nArray usage:\n\nexport default {\n  buildConfig: {\n    input: ['src/index.ts', 'src/index2.ts'],\n  },\n};\n\n\nObject usage:\n\nWhen you need to modify the output file name in bundle mode, you can use an\nobject configuration.\n\nThe key of the object is the file name of the output, and the value is the file\npath of the source code.\n\nexport default defineConfig({\n  buildConfig: {\n    format: 'esm',\n    input: {\n      'index.esm': './src/index.ts',\n    },\n  },\n});\n\n\n\njsx#\n\nSpecify the compilation method for JSX, which by default supports React 17 and\nhigher versions and automatically injects JSX runtime code.\n\n * Type: automatic | transform\n * Default: automatic\n\nIf you need to support React 16, you can set jsx to transform:\n\nexport default defineConfig({\n  buildConfig: {\n    jsx: 'transform',\n  },\n});\n\n\nTIP\n\nFor more information about JSX Transform, you can refer to the following links:\n\n * React Blog - Introducing the New JSX Transform.\n * esbuild - JSX. :::\n\n\nmetafile#\n\nThis option is used for build analysis. When enabled, esbuild will generate\nmetadata about the build in JSON format.\n\n * Type: boolean\n * Default: false\n * Build Type: Only supported for buildType: 'bundle'\n\nTo enable metafile generation:\n\nexport default defineConfig({\n  buildConfig: {\n    buildType: 'bundle',\n    metafile: true,\n  },\n});\n\n\nAfter executing the build, a metafile-[xxx].json file will be generated in the\noutput directory. You can use tools like esbuild analyze and bundle-buddy for\nvisual analysis.\n\n\nminify#\n\nUse esbuild or terser to compress code, also pass terserOptions\n\n * Type: 'terser' | 'esbuild' | false | object\n * Default: false\n\nexport default {\n  buildConfig: {\n    minify: {\n      compress: {\n        drop_console: true,\n      },\n    },\n  },\n};\n\n\n\noutDir#\n\nSpecifies the output directory of the build\n\n * Type: string\n * Default: dist\n\n\nplatform#\n\nGenerates code for the node environment by default, you can also specify browser\nwhich will generate code for the browser environment\n\n * Type: 'browser' | 'node'\n * Default: node\n\n\nredirect#\n\nIn buildType: 'bundleless' build mode, the reference path is redirected to\nensure that it points to the correct product, e.g:\n\n * import '. /index.less' will be rewritten to import '. /index.css'\n * would be rewritten as to `` (depending on the situation)\n\nIn some scenarios, you may not need these functions, then you can turn it off\nwith this configuration, and its reference path will not be changed after\nturning it off.\n\nexport default {\n  buildConfig: {\n    redirect: {\n      alias: false, // Turn off modifying alias paths\n      style: false, // Turn off modifying the path to the style file\n      asset: false, // Turn off modifying the path to the resource file\n    },\n  },\n};\n\n\n\nsideEffects#\n\nModule sideEffects\n\n * Type: RegExg[] | (filePath: string, isExternal: boolean) => boolean | boolean\n * Default: undefined\n\nNormally, we configure the module's side effects via the sideEffects field in\npackage.json, but in some cases, The package.json of a third-party package is\nunreliable.Such as when we reference a third-party package style file\n\nimport 'other-package/dist/index.css';\n\n\nBut the package.json of this third-party package does not have the style file\nconfigured in the sideEffects\n\n{\n  \"sideEffects\": [\"dist/index.js\"]\n}\n\n\nAt the same time you set style.inject to true and you will see a warning message\nlike this in the console\n\n[LIBUILD:ESBUILD_WARN] Ignoring this import because \"other-package/dist/index.css\" was marked as having no side effects\n\n\nAt this point, you can use this configuration item to manually configure the\nmodule's \"sideEffects\" to support regular and functional forms.\n\nexport default defineConfig({\n  buildConfig: {\n    sideEffects: [/\\.css$/],\n    // or\n    // sideEffects: (filePath, isExternal) => /\\.css$/.test(filePath),\n  },\n});\n\n\n\nsourceDir#\n\nSpecify the source directory of the build, default is src, which is used to\ngenerate the corresponding product directory based on the source directory\nstructure when building bundleless.\n\n * Type: string\n * Default: src\n\n\nsourceMap#\n\nWhether to generate sourceMap or not\n\n * Type: boolean | 'inline' | 'external'\n * Default: false\n\n\nsourceType#\n\nSets the format of the source code. By default, the source code will be treated\nas EsModule. When the source code is using CommonJS, you need to set commonjs.\n\n * Type: 'commonjs' | 'module'\n * Default: 'module'\n\n\nsplitting#\n\nWhether to enable code splitting\n\n * Type: boolean\n * Default: false\n\n\nstyle#\n\nConfigure style-related configuration\n\n\nstyle.less#\n\nless-related configuration\n\n\nstyle.less.lessOptions#\n\nRefer to less for detailed configuration\n\n * Type: object\n * Default: { javascriptEnabled: true }\n\n\nstyle.less.additionalData#\n\nAdd Less code to the beginning of the entry file.\n\n * Type: string\n * Default: undefined\n\nexport default {\n  buildConfig: {\n    style: {\n      less: {\n        additionalData: `@base-color: #c6538c;`,\n      },\n    },\n  },\n};\n\n\n\nstyle.less.implementation#\n\nConfigure the implementation library used by Less, if not specified, the\nbuilt-in version used is 4.1.3.\n\n * Type: string | object\n * Default: undefined\n\nSpecify the implementation library for Less when the object type is specified.\n\nexport default {\n  buildConfig: {\n    style: {\n      less: {\n        implementation: require('less'),\n      },\n    },\n  },\n};\n\n\nFor the string type, specify the path to the implementation library for Less\n\nexport default {\n  buildConfig: {\n    style: {\n      less: {\n        implementation: require.resolve('less'),\n      },\n    },\n  },\n};\n\n\n\nstyle.sass#\n\nsass-related configuration.\n\n\nstyle.sass.sassOptions#\n\nRefer to node-sass for detailed configuration.\n\n * Type: object\n * Default: {}\n\n\nstyle.sass.additionalData#\n\nAdd Sass code to the beginning of the entry file.\n\n * Type: string | Function\n * Default: undefined\n\nexport default {\n  buildConfig: {\n    style: {\n      sass: {\n        additionalData: `$base-color: #c6538c;\n          $border-dark: rgba($base-color, 0.88);`,\n      },\n    },\n  },\n};\n\n\n\nstyle.sass.implementation#\n\nConfigure the implementation library used by Sass, the built-in version used is\n1.5.4 if not specified.\n\n * Type: string | object\n * Default: undefined\n\nSpecify the implementation library for Sass when the object type is specified.\n\nexport default {\n  buildConfig: {\n    style: {\n      sass: {\n        implementation: require('sass'),\n      },\n    },\n  },\n};\n\n\nFor the string type, specify the path to the Sass implementation library\n\nexport default {\n  buildConfig: {\n    style: {\n      sass: {\n        implementation: require.resolve('sass'),\n      },\n    },\n  },\n};\n\n\n\nstyle.postcss#\n\n * plugins\n * processOptions\n\nSee PostCSS for detailed configuration\n\nBasic usage：\n\nexport default defineConfig({\n  buildConfig: {\n    style: {\n      postcss: {\n        plugins: [yourPostCSSPlugin],\n      },\n    },\n  },\n});\n\n\n\nstyle.inject#\n\nConfigure whether to insert CSS styles into JavaScript code in bundle mode.\n\n * Type: boolean\n * Default: false\n\nSet inject to true to enable this feature:\n\nexport default defineConfig({\n  buildConfig: {\n    inject: true,\n  },\n});\n\n\nOnce enabled, you will see the CSS code referenced in the source code included\nin the bundled JavaScript output.\n\nFor example, if you write import './index.scss' in the source code, you will see\nthe following code in the output:\n\n// node_modules/style-inject/dist/style-inject.es.js\nfunction styleInject(css, ref) {\n  // ...\n}\nvar style_inject_es_default = styleInject;\n\n// src/index.scss\nvar css_248z = '.body {\\n color: black;\\n}';\nstyle_inject_es_default(css_248z);\n\n\nTIP\n\nAfter enabling inject, you need to pay attention to the following points:\n\n * @import in CSS files will not be processed. If your CSS file contains\n   @import, you need to manually import the CSS file in the JS file (less and\n   scss files are not required because they have preprocessing).\n * Consider the impact of sideEffects. By default, our builder assumes that CSS\n   has side effects. If the sideEffects field is set in your project or\n   third-party package's package.json and does not include this CSS file, you\n   will receive a warning:\n\n[LIBUILD:ESBUILD_WARN] Ignoring this import because \"src/index.scss\" was marked as having no side effects by plugin \"libuild:adapter\"\n\n\nYou can resolve this by configuring sideEffects.\n\n\nstyle.autoModules#\n\nEnable CSS Modules automatically based on the filename.\n\n * Type: boolean | RegExp\n * Default: true\n\ntrue : Enables CSS Modules for style files ending with .module.css .module.less\n.module.scss .module.sass filenames\n\nfalse : Disable CSS Modules.\n\nRegExp : Enables CSS Modules for all files that match the regular condition.\n\n\nstyle.modules#\n\nCSS Modules configuration\n\n * Type: object\n * Default: {}\n\nA common configuration is localsConvention, which changes the class name\ngeneration rules for css modules\n\nexport default {\n  buildConfig: {\n    style: {\n      modules: {\n        localsConvention: 'camelCaseOnly',\n      },\n    },\n  },\n};\n\n\nFor the following styles\n\n.box-title {\n  color: red;\n}\n\n\nYou can use styles.boxTitle to access\n\nFor detailed configuration see postcss-modules\n\n\nstyle.tailwindcss#\n\ntailwindcss related configuration\n\n * Type: object | Function\n * Default: see configuration details below\n\nconst tailwind = {\n  content: [\n    './config/html/**/*.html',\n    './config/html/**/*.ejs',\n    './config/html/**/*.hbs',\n    './src/**/*.js',\n    './src/**/*.jsx',\n    './src/**/*.ts',\n    './src/**/*.tsx',\n    './storybook/**/*',\n  ],\n};\n\n\nWhen the value is of type object, it is merged with the default configuration\nvia Object.assign.\n\nWhen the value is of type Function, the object returned by the function is\nmerged with the default configuration via Object.assign.\n\nThe theme property is not allowed, otherwise the build will fail, using\ndesignSystem as the Tailwind CSS Theme configuration.\n\nThe rest of the usage is the same as Tailwind CSS: Quick Portal.\n\n\ntarget#\n\ntarget is used to set the target environment for the generated JavaScript code.\nIt enables Module Tools to transform JavaScript syntax that is not recognized by\nthe target environment into older versions of JavaScript syntax that are\ncompatible with these environments.\n\n * Type:\n\ntype Target =\n  | 'es5'\n  | 'es6'\n  | 'es2015'\n  | 'es2016'\n  | 'es2017'\n  | 'es2018'\n  | 'es2019'\n  | 'es2020'\n  | 'es2021'\n  | 'es2022'\n  | 'esnext';\n\n\n * Default: 'es6'\n\nFor example, compile the code to es5 syntax:\n\nexport default defineConfig({\n  buildConfig: {\n    target: 'es5',\n  },\n});\n\n\n\ntransformImport#\n\nUsing SWC provides the same ability and configuration as babel-plugin-import.\n\n * Type: object[]\n * Default: []\n\nThe elements of the array are configuration objects for babel-plugin-import,\nwhich can be referred to options。\n\nExample:\n\nexport default defineConfig({\n  buildConfig: {\n    transformImport: [\n      // babel-plugin-import`s options config\n      {\n        libraryName: 'foo',\n        style: true,\n      },\n    ],\n  },\n});\n\n\n\nNotes#\n\nReference the Import Plugin - Notes\n\n\numdGlobals#\n\nSpecify global variables for external import of umd products\n\n * Type: Record\n * Default: {}\n\nexport default {\n  buildConfig: {\n    umdGlobals: {\n      react: 'React',\n      'react-dom': 'ReactDOM',\n    },\n  },\n};\n\n\nAt this point, react and react-dom will be seen as global variables imported\nexternally and will not be packed into the umd product, but will be accessible\nby way of global.React and global.ReactDOM\n\n\numdModuleName#\n\nSpecifies the module name of the umd product\n\n * Type: string | Function\n * Default: name => name\n\nexport default {\n  buildConfig: {\n    format: 'umd',\n    umdModuleName: 'myLib',\n  },\n};\n\n\nAt this point the umd product will go to mount on global.myLib\n\n:::tip\n\n * The module name of the umd product must not conflict with the global variable\n   name.\n * Module names will be converted to camelCase, e.g. my-lib will be converted to\n   myLib, refer to toIdentifier.\n\nAlso the function form can take one parameter, which is the output path of the\ncurrent package file\n\nexport default {\n  buildConfig: {\n    format: 'umd',\n    umdModuleName: path => {\n      if (path.includes('index')) {\n        return 'myLib';\n      } else {\n        return 'myLib2';\n      }\n    },\n  },\n};\n","frontmatter":{"sidebar_position":1},"_filepath":"/Users/bytedance/github/targeral/modern-js/packages/document/module-doc/docs/en/api/config/build-config.md","_relativePath":"en/api/config/build-config.md"},{"id":1,"title":"buildPreset","routePath":"/module-tools/en/api/config/build-preset","lang":"en","toc":[{"text":"string","id":"string","depth":2,"charIndex":140},{"text":"\\'npm-library\\'","id":"\\'npm-library\\'","depth":3,"charIndex":-1},{"text":"\\'npm-library-with-umd\\'","id":"\\'npm-library-with-umd\\'","depth":3,"charIndex":-1},{"text":"\\'npm-component\\'","id":"\\'npm-component\\'","depth":3,"charIndex":-1},{"text":"\\'npm-component-with-umd\\'","id":"\\'npm-component-with-umd\\'","depth":3,"charIndex":-1},{"text":"About the ECMAScript versions supported by the presets and {es5.... .esnext}","id":"about-the-ecmascript-versions-supported-by-the-presets-and-{es5-esnext}","depth":3,"charIndex":3597},{"text":"Function","id":"function","depth":2,"charIndex":4082},{"text":"Function Parameters","id":"function-parameters","depth":3,"charIndex":4635},{"text":"preset","id":"preset","depth":4,"charIndex":4816},{"text":"extendPreset","id":"extendpreset","depth":4,"charIndex":5114}],"domain":"","content":"#\n\nA build preset string or preset function. Provides out-of-the-box build\nconfiguration\n\n * Type: string | Function\n * Default: undefined\n\n\nstring#\n\nThe string form allows you to use the built-in presets directly\n\n\n\nexport default defineConfig({\n  buildPreset: 'npm-library',\n});\n\n\n\n'npm-library'#\n\nLibrary generic schema used under class NPM package manager, contains esm and\ncjs Bundle products, and includes a type file.\n\nINFO\n\nAbout the class NPM Package Manager\n\n * npm\n * yarn\n * pnpm\n\n{\n  \"main\": \". /dist/lib/index.js\",\n  \"module\": \". /dist/es/index.js\",\n  \"types\": \". /dist/types/index.d.ts\"\n}\n\n\nThe build configuration corresponding to the preset string.\n\nexport const buildConfig = [\n  {\n    format: 'cjs',\n    target: 'es6',\n    buildType: 'bundle',\n    outDir: './dist/lib',\n  },\n  {\n    format: 'esm',\n    target: 'es6',\n    buildType: 'bundle',\n    outDir: './dist/es',\n  },\n  {\n    buildType: 'bundle',\n    outDir: './dist/types',\n    dts: {\n      only: true,\n    },\n  },\n];\n\n\n\n'npm-library-with-umd'#\n\nUsed under class NPM package manager, and Library supports a similar pattern to\nunpkg. Additional umd products are provided on top of the pre-defined\nnpm-library.\n\n{\n    \"main\": \". /dist/lib/index.js\",\n    \"module\": \". /dist/es/index.js\",\n    \"types\": \". /dist/types/index.d.ts\",\n    \"unpkg\": \". /dist/umd/index.js\",\n};\n\n\nThe build configuration corresponding to the preset string.\n\nexport const buildConfig = [\n  {\n    format: 'cjs',\n    target: 'es6',\n    buildType: 'bundle',\n    outDir: './dist/lib',\n  },\n  {\n    format: 'esm',\n    target: 'es6',\n    buildType: 'bundle',\n    outDir: './dist/es',\n  },\n  {\n    format: 'umd',\n    target: 'es6',\n    buildType: 'bundle',\n    outDir: './dist/umd',\n  },\n  {\n    buildType: 'bundle',\n    outDir: './dist/types',\n    dts: {\n      only: true,\n    },\n  },\n];\n\n\n\n'npm-component'#\n\nA generic pattern for components (libraries) used under the class NPM package\nmanager. Contains both esm and cjs Bundleless products (for easy Tree shaking\noptimization), as well as including a copy of the type file.\n\nFor style files included in the source code, the products provide the compiled\nproduct of the style and the source file of the style.\n\n{\n    \"main\": \". /dist/lib/index.js\", // bundleless type\n    \"module\": \". /dist/es/index.js\", // bundleless type\n    \"types\": \". /dist/types/index.d.ts\",\n};\n\n\nThe pre-defined strings correspond to the build configuration.\n\nexport const buildConfig = [\n  {\n    format: 'cjs',\n    target: 'es6',\n    buildType: 'bundleless',\n    outDir: './dist/lib',\n  },\n  {\n    format: 'esm',\n    target: 'es6',\n    buildType: 'bundleless',\n    outDir: './dist/es',\n  },\n  {\n    buildType: 'bundleless',\n    outDir: './dist/types',\n    dts: {\n      only: true,\n    },\n  },\n];\n\n\n\n'npm-component-with-umd'#\n\nComponent (library) used under class NPM package manager, with support for class\nunpkg schema. Additional umd products are provided on top of the pre-defined\nnpm-component.\n\n{\n    \"main\": \". /dist/lib/index.js\", // bundleless type\n    \"module\": \". /dist/es/index.js\", // bundleless type\n    \"types\": \". /dist/types/index.d.ts\",\n    \"unpkg\": \". /dist/umd/index.js\",\n};\n\n\nexport const buildConfig = [\n  {\n    format: 'cjs',\n    target: 'es6',\n    buildType: 'bundleless',\n    outDir: './dist/lib',\n  },\n  {\n    format: 'esm',\n    target: 'es6',\n    buildType: 'bundleless',\n    outDir: './dist/es',\n  },\n  {\n    format: 'umd',\n    target: 'es6',\n    buildType: 'bundle',\n    outDir: './dist/umd',\n  },\n  {\n    buildType: 'bundleless',\n    outDir: './dist/types',\n    dts: {\n      only: true,\n    },\n  },\n];\n\n\n\nAbout the ECMAScript versions supported by the presets and {es5.... .esnext}#\n\nWhen you want to use a buildPreset preset that supports other ECMAScript\nversions, you can directly add the supported versions to the 'npm-library',\n'npm-library-with-umd', 'npm-component', 'npm-component-with-umd' presets.\n\nFor example, if you want the 'npm-library' preset to support 'es2017', you can\nconfigure it as follows.\n\n\n\nexport default defineConfig({\n  buildPreset: 'npm-library-es2017',\n});\n\n\n\nFunction#\n\nThe way the function is configured, you can get the preset value from the preset\nparameter and then modify the build configuration inside to customize your build\nconfiguration.\n\nThe following is an example of how a function can be configured to compress a\nbuild product.\n\n\n\nexport default defineConfig({\n  buildPreset({ preset }) {\n    const { NPM_LIBRARY } = preset;\n    return NPM_LIBRARY.map(config => {\n      config.minify = {\n        compress: {\n          drop_console: true,\n        },\n      };\n      return config;\n    });\n  },\n});\n\n\n\nFunction Parameters#\n\nThe function form of buildPreset contains a function parameter in the form of an\nobject. The object contains the following fields.\n\n * preset\n * extendPreset\n\npreset#\n\nType: Object\n\nContains the build configurations corresponding to all available build presets.\nBuild configurations can be used by means of the strings supported by\nbuildPreset or by means of underscore commands for those strings. The following\nare examples of the use of both approaches.\n\nextendPreset#\n\nType: Function\n\nTool function for extending a buildPreset to modify the build configuration\ncorresponding to the buildPreset.\n\n> The base uses something like {...oldBuildConfig, ...extendBuildConfig}\n> approach to processing.\n\nFor example, adding the define configuration to the 'npm-library' build preset.\n\n\n\nexport default defineConfig({\n  buildPreset({ extendPreset }) {\n    return extendPreset('npm-library', {\n      define: {\n        VERSION: '1.0.1',\n      },\n    });\n  },\n});\n","frontmatter":{"sidebar_position":2},"_filepath":"/Users/bytedance/github/targeral/modern-js/packages/document/module-doc/docs/en/api/config/build-preset.mdx","_relativePath":"en/api/config/build-preset.mdx"},{"id":2,"title":"designSystem","routePath":"/module-tools/en/api/config/design-system","lang":"en","toc":[{"text":"Screens","id":"screens","depth":2,"charIndex":13310},{"text":"Max-width breakpoints","id":"max-width-breakpoints","depth":3,"charIndex":14822},{"text":"Multiple range breakpoints","id":"multiple-range-breakpoints","depth":3,"charIndex":15613},{"text":"Custom media queries","id":"custom-media-queries","depth":3,"charIndex":16389},{"text":"Print styles","id":"print-styles","depth":3,"charIndex":16696},{"text":"Dark Mode","id":"dark-mode","depth":3,"charIndex":17149},{"text":"Colors","id":"colors","depth":2,"charIndex":17506},{"text":"Spacing","id":"spacing","depth":2,"charIndex":17904},{"text":"Core plugins","id":"core-plugins","depth":2,"charIndex":18514},{"text":"Customizing the default configuration","id":"customizing-the-default-configuration","depth":2,"charIndex":19626},{"text":"Override the default configuration","id":"override-the-default-configuration","depth":3,"charIndex":19872},{"text":"Extending the default configuration","id":"extending-the-default-configuration","depth":3,"charIndex":20614},{"text":"Referencing other values","id":"referencing-other-values","depth":3,"charIndex":21513},{"text":"Disabling the entire core plugin","id":"disabling-the-entire-core-plugin","depth":3,"charIndex":22950},{"text":"Adding your own key","id":"adding-your-own-key","depth":3,"charIndex":23604},{"text":"Configuration references","id":"configuration-references","depth":2,"charIndex":24905}],"domain":"","content":"#\n\nThis chapter describes the configuration related to designSystem.\n\nTIP\n\nThe Tailwind CSS feature needs to be enabled first via pnpm run new.\n\n * Type: object\n * Default: see configuration details below.\n\nconst designSystem = {\n  screens: {\n    sm: '640px',\n    md: '768px',\n    lg: '1024px',\n    xl: '1280px',\n  },\n  colors: {\n    transparent: 'transparent',\n    current: 'currentColor',\n\n    black: '#000',\n    white: '#fff',\n\n    gray: {\n      100: '#f7fafc',\n      200: '#edf2f7',\n      300: '#e2e8f0',\n      400: '#cbd5e0',\n      500: '#a0aec0',\n      600: '#718096',\n      700: '#4a5568',\n      800: '#2d3748',\n      900: '#1a202c',\n    },\n    red: {\n      100: '#fff5f5',\n      200: '#fed7d7',\n      300: '#feb2b2',\n      400: '#fc8181',\n      500: '#f56565',\n      600: '#e53e3e',\n      700: '#c53030',\n      800: '#9b2c2c',\n      900: '#742a2a',\n    },\n    orange: {\n      100: '#fffaf0',\n      200: '#feebc8',\n      300: '#fbd38d',\n      400: '#f6ad55',\n      500: '#ed8936',\n      600: '#dd6b20',\n      700: '#c05621',\n      800: '#9c4221',\n      900: '#7b341e',\n    },\n    yellow: {\n      100: '#fffff0',\n      200: '#fefcbf',\n      300: '#faf089',\n      400: '#f6e05e',\n      500: '#ecc94b',\n      600: '#d69e2e',\n      700: '#b7791f',\n      800: '#975a16',\n      900: '#744210',\n    },\n    green: {\n      100: '#f0fff4',\n      200: '#c6f6d5',\n      300: '#9ae6b4',\n      400: '#68d391',\n      500: '#48bb78',\n      600: '#38a169',\n      700: '#2f855a',\n      800: '#276749',\n      900: '#22543d',\n    },\n    teal: {\n      100: '#e6fffa',\n      200: '#b2f5ea',\n      300: '#81e6d9',\n      400: '#4fd1c5',\n      500: '#38b2ac',\n      600: '#319795',\n      700: '#2c7a7b',\n      800: '#285e61',\n      900: '#234e52',\n    },\n    blue: {\n      100: '#ebf8ff',\n      200: '#bee3f8',\n      300: '#90cdf4',\n      400: '#63b3ed',\n      500: '#4299e1',\n      600: '#3182ce',\n      700: '#2b6cb0',\n      800: '#2c5282',\n      900: '#2a4365',\n    },\n    indigo: {\n      100: '#ebf4ff',\n      200: '#c3dafe',\n      300: '#a3bffa',\n      400: '#7f9cf5',\n      500: '#667eea',\n      600: '#5a67d8',\n      700: '#4c51bf',\n      800: '#434190',\n      900: '#3c366b',\n    },\n    purple: {\n      100: '#faf5ff',\n      200: '#e9d8fd',\n      300: '#d6bcfa',\n      400: '#b794f4',\n      500: '#9f7aea',\n      600: '#805ad5',\n      700: '#6b46c1',\n      800: '#553c9a',\n      900: '#44337a',\n    },\n    pink: {\n      100: '#fff5f7',\n      200: '#fed7e2',\n      300: '#fbb6ce',\n      400: '#f687b3',\n      500: '#ed64a6',\n      600: '#d53f8c',\n      700: '#b83280',\n      800: '#97266d',\n      900: '#702459',\n    },\n  },\n  spacing: {\n    px: '1px',\n    0: '0',\n    1: '0.25rem',\n    2: '0.5rem',\n    3: '0.75rem',\n    4: '1rem',\n    5: '1.25rem',\n    6: '1.5rem',\n    8: '2rem',\n    10: '2.5rem',\n    12: '3rem',\n    16: '4rem',\n    20: '5rem',\n    24: '6rem',\n    32: '8rem',\n    40: '10rem',\n    48: '12rem',\n    56: '14rem',\n    64: '16rem',\n  },\n  backgroundColor: theme => theme('colors'),\n  backgroundOpacity: theme => theme('opacity'),\n  backgroundPosition: {\n    bottom: 'bottom',\n    center: 'center',\n    left: 'left',\n    'left-bottom': 'left bottom',\n    'left-top': 'left top',\n    right: 'right',\n    'right-bottom': 'right bottom',\n    'right-top': 'right top',\n    top: 'top',\n  },\n  backgroundSize: {\n    auto: 'auto',\n    cover: 'cover',\n    contain: 'contain',\n  },\n  borderColor: theme => ({\n    ...theme('colors'),\n    default: theme('colors.gray.300', 'currentColor'),\n  }),\n  borderOpacity: theme => theme('opacity'),\n  borderRadius: {\n    none: '0',\n    sm: '0.125rem',\n    default: '0.25rem',\n    md: '0.375rem',\n    lg: '0.5rem',\n    full: '9999px',\n  },\n  borderWidth: {\n    default: '1px',\n    0: '0',\n    2: '2px',\n    4: '4px',\n    8: '8px',\n  },\n  boxShadow: {\n    xs: '0 0 0 1px rgba(0, 0, 0, 0.05)',\n    sm: '0 1px 2px 0 rgba(0, 0, 0, 0.05)',\n    default: '0 1px 3px 0 rgba(0, 0, 0, 0.1), 0 1px 2px 0 rgba(0, 0, 0, 0.06)',\n    md: '0 4px 6px -1px rgba(0, 0, 0, 0.1), 0 2px 4px -1px rgba(0, 0, 0, 0.06)',\n    lg: '0 10px 15px -3px rgba(0, 0, 0, 0.1), 0 4px 6px -2px rgba(0, 0, 0, 0.05)',\n    xl: '0 20px 25px -5px rgba(0, 0, 0, 0.1), 0 10px 10px -5px rgba(0, 0, 0, 0.04)',\n    '2xl': '0 25px 50px -12px rgba(0, 0, 0, 0.25)',\n    inner: 'inset 0 2px 4px 0 rgba(0, 0, 0, 0.06)',\n    outline: '0 0 0 3px rgba(66, 153, 225, 0.5)',\n    none: 'none',\n  },\n  container: {},\n  cursor: {\n    auto: 'auto',\n    default: 'default',\n    pointer: 'pointer',\n    wait: 'wait',\n    text: 'text',\n    move: 'move',\n    'not-allowed': 'not-allowed',\n  },\n  divideColor: theme => theme('borderColor'),\n  divideOpacity: theme => theme('borderOpacity'),\n  divideWidth: theme => theme('borderWidth'),\n  fill: {\n    current: 'currentColor',\n  },\n  flex: {\n    1: '1 1 0%',\n    auto: '1 1 auto',\n    initial: '0 1 auto',\n    none: 'none',\n  },\n  flexGrow: {\n    0: '0',\n    default: '1',\n  },\n  flexShrink: {\n    0: '0',\n    default: '1',\n  },\n  fontFamily: {\n    sans: [\n      'system-ui',\n      '-apple-system',\n      'BlinkMacSystemFont',\n      '\"Segoe UI\"',\n      'Roboto',\n      '\"Helvetica Neue\"',\n      'Arial',\n      '\"Noto Sans\"',\n      'sans-serif',\n      '\"Apple Color Emoji\"',\n      '\"Segoe UI Emoji\"',\n      '\"Segoe UI Symbol\"',\n      '\"Noto Color Emoji\"',\n    ],\n    serif: ['Georgia', 'Cambria', '\"Times New Roman\"', 'Times', 'serif'],\n    mono: [\n      'Menlo',\n      'Monaco',\n      'Consolas',\n      '\"Liberation Mono\"',\n      '\"Courier New\"',\n      'monospace',\n    ],\n  },\n  fontSize: {\n    xs: '0.75rem',\n    sm: '0.875rem',\n    base: '1rem',\n    lg: '1.125rem',\n    xl: '1.25rem',\n    '2xl': '1.5rem',\n    '3xl': '1.875rem',\n    '4xl': '2.25rem',\n    '5xl': '3rem',\n    '6xl': '4rem',\n  },\n  fontWeight: {\n    hairline: '100',\n    thin: '200',\n    light: '300',\n    normal: '400',\n    medium: '500',\n    semibold: '600',\n    bold: '700',\n    extrabold: '800',\n    black: '900',\n  },\n  height: theme => ({\n    auto: 'auto',\n    ...theme('spacing'),\n    full: '100%',\n    screen: '100vh',\n  }),\n  inset: {\n    0: '0',\n    auto: 'auto',\n  },\n  letterSpacing: {\n    tighter: '-0.05em',\n    tight: '-0.025em',\n    normal: '0',\n    wide: '0.025em',\n    wider: '0.05em',\n    widest: '0.1em',\n  },\n  lineHeight: {\n    none: '1',\n    tight: '1.25',\n    snug: '1.375',\n    normal: '1.5',\n    relaxed: '1.625',\n    loose: '2',\n    3: '.75rem',\n    4: '1rem',\n    5: '1.25rem',\n    6: '1.5rem',\n    7: '1.75rem',\n    8: '2rem',\n    9: '2.25rem',\n    10: '2.5rem',\n  },\n  listStyleType: {\n    none: 'none',\n    disc: 'disc',\n    decimal: 'decimal',\n  },\n  margin: (theme, { negative }) => ({\n    auto: 'auto',\n    ...theme('spacing'),\n    ...negative(theme('spacing')),\n  }),\n  maxHeight: {\n    full: '100%',\n    screen: '100vh',\n  },\n  maxWidth: (theme, { breakpoints }) => ({\n    none: 'none',\n    xs: '20rem',\n    sm: '24rem',\n    md: '28rem',\n    lg: '32rem',\n    xl: '36rem',\n    '2xl': '42rem',\n    '3xl': '48rem',\n    '4xl': '56rem',\n    '5xl': '64rem',\n    '6xl': '72rem',\n    full: '100%',\n    ...breakpoints(theme('screens')),\n  }),\n  minHeight: {\n    0: '0',\n    full: '100%',\n    screen: '100vh',\n  },\n  minWidth: {\n    0: '0',\n    full: '100%',\n  },\n  objectPosition: {\n    bottom: 'bottom',\n    center: 'center',\n    left: 'left',\n    'left-bottom': 'left bottom',\n    'left-top': 'left top',\n    right: 'right',\n    'right-bottom': 'right bottom',\n    'right-top': 'right top',\n    top: 'top',\n  },\n  opacity: {\n    0: '0',\n    25: '0.25',\n    50: '0.5',\n    75: '0.75',\n    100: '1',\n  },\n  order: {\n    first: '-9999',\n    last: '9999',\n    none: '0',\n    1: '1',\n    2: '2',\n    3: '3',\n    4: '4',\n    5: '5',\n    6: '6',\n    7: '7',\n    8: '8',\n    9: '9',\n    10: '10',\n    11: '11',\n    12: '12',\n  },\n  padding: theme => theme('spacing'),\n  placeholderColor: theme => theme('colors'),\n  placeholderOpacity: theme => theme('opacity'),\n  space: (theme, { negative }) => ({\n    ...theme('spacing'),\n    ...negative(theme('spacing')),\n  }),\n  stroke: {\n    current: 'currentColor',\n  },\n  strokeWidth: {\n    0: '0',\n    1: '1',\n    2: '2',\n  },\n  textColor: theme => theme('colors'),\n  textOpacity: theme => theme('opacity'),\n  width: theme => ({\n    auto: 'auto',\n    ...theme('spacing'),\n    '1/2': '50%',\n    '1/3': '33.333333%',\n    '2/3': '66.666667%',\n    '1/4': '25%',\n    '2/4': '50%',\n    '3/4': '75%',\n    '1/5': '20%',\n    '2/5': '40%',\n    '3/5': '60%',\n    '4/5': '80%',\n    '1/6': '16.666667%',\n    '2/6': '33.333333%',\n    '3/6': '50%',\n    '4/6': '66.666667%',\n    '5/6': '83.333333%',\n    '1/12': '8.333333%',\n    '2/12': '16.666667%',\n    '3/12': '25%',\n    '4/12': '33.333333%',\n    '5/12': '41.666667%',\n    '6/12': '50%',\n    '7/12': '58.333333%',\n    '8/12': '66.666667%',\n    '9/12': '75%',\n    '10/12': '83.333333%',\n    '11/12': '91.666667%',\n    full: '100%',\n    screen: '100vw',\n  }),\n  zIndex: {\n    auto: 'auto',\n    0: '0',\n    10: '10',\n    20: '20',\n    30: '30',\n    40: '40',\n    50: '50',\n  },\n  gap: theme => theme('spacing'),\n  gridTemplateColumns: {\n    none: 'none',\n    1: 'repeat(1, minmax(0, 1fr))',\n    2: 'repeat(2, minmax(0, 1fr))',\n    3: 'repeat(3, minmax(0, 1fr))',\n    4: 'repeat(4, minmax(0, 1fr))',\n    5: 'repeat(5, minmax(0, 1fr))',\n    6: 'repeat(6, minmax(0, 1fr))',\n    7: 'repeat(7, minmax(0, 1fr))',\n    8: 'repeat(8, minmax(0, 1fr))',\n    9: 'repeat(9, minmax(0, 1fr))',\n    10: 'repeat(10, minmax(0, 1fr))',\n    11: 'repeat(11, minmax(0, 1fr))',\n    12: 'repeat(12, minmax(0, 1fr))',\n  },\n  gridColumn: {\n    auto: 'auto',\n    'span-1': 'span 1 / span 1',\n    'span-2': 'span 2 / span 2',\n    'span-3': 'span 3 / span 3',\n    'span-4': 'span 4 / span 4',\n    'span-5': 'span 5 / span 5',\n    'span-6': 'span 6 / span 6',\n    'span-7': 'span 7 / span 7',\n    'span-8': 'span 8 / span 8',\n    'span-9': 'span 9 / span 9',\n    'span-10': 'span 10 / span 10',\n    'span-11': 'span 11 / span 11',\n    'span-12': 'span 12 / span 12',\n  },\n  gridColumnStart: {\n    auto: 'auto',\n    1: '1',\n    2: '2',\n    3: '3',\n    4: '4',\n    5: '5',\n    6: '6',\n    7: '7',\n    8: '8',\n    9: '9',\n    10: '10',\n    11: '11',\n    12: '12',\n    13: '13',\n  },\n  gridColumnEnd: {\n    auto: 'auto',\n    1: '1',\n    2: '2',\n    3: '3',\n    4: '4',\n    5: '5',\n    6: '6',\n    7: '7',\n    8: '8',\n    9: '9',\n    10: '10',\n    11: '11',\n    12: '12',\n    13: '13',\n  },\n  gridTemplateRows: {\n    none: 'none',\n    1: 'repeat(1, minmax(0, 1fr))',\n    2: 'repeat(2, minmax(0, 1fr))',\n    3: 'repeat(3, minmax(0, 1fr))',\n    4: 'repeat(4, minmax(0, 1fr))',\n    5: 'repeat(5, minmax(0, 1fr))',\n    6: 'repeat(6, minmax(0, 1fr))',\n  },\n  gridRow: {\n    auto: 'auto',\n    'span-1': 'span 1 / span 1',\n    'span-2': 'span 2 / span 2',\n    'span-3': 'span 3 / span 3',\n    'span-4': 'span 4 / span 4',\n    'span-5': 'span 5 / span 5',\n    'span-6': 'span 6 / span 6',\n  },\n  gridRowStart: {\n    auto: 'auto',\n    1: '1',\n    2: '2',\n    3: '3',\n    4: '4',\n    5: '5',\n    6: '6',\n    7: '7',\n  },\n  gridRowEnd: {\n    auto: 'auto',\n    1: '1',\n    2: '2',\n    3: '3',\n    4: '4',\n    5: '5',\n    6: '6',\n    7: '7',\n  },\n  transformOrigin: {\n    center: 'center',\n    top: 'top',\n    'top-right': 'top right',\n    right: 'right',\n    'bottom-right': 'bottom right',\n    bottom: 'bottom',\n    'bottom-left': 'bottom left',\n    left: 'left',\n    'top-left': 'top left',\n  },\n  scale: {\n    0: '0',\n    50: '.5',\n    75: '.75',\n    90: '.9',\n    95: '.95',\n    100: '1',\n    105: '1.05',\n    110: '1.1',\n    125: '1.25',\n    150: '1.5',\n  },\n  rotate: {\n    '-180': '-180deg',\n    '-90': '-90deg',\n    '-45': '-45deg',\n    0: '0',\n    45: '45deg',\n    90: '90deg',\n    180: '180deg',\n  },\n  translate: (theme, { negative }) => ({\n    ...theme('spacing'),\n    ...negative(theme('spacing')),\n    '-full': '-100%',\n    '-1/2': '-50%',\n    '1/2': '50%',\n    full: '100%',\n  }),\n  skew: {\n    '-12': '-12deg',\n    '-6': '-6deg',\n    '-3': '-3deg',\n    0: '0',\n    3: '3deg',\n    6: '6deg',\n    12: '12deg',\n  },\n  transitionProperty: {\n    none: 'none',\n    all: 'all',\n    default:\n      'background-color, border-color, color, fill, stroke, opacity, box-shadow, transform',\n    colors: 'background-color, border-color, color, fill, stroke',\n    opacity: 'opacity',\n    shadow: 'box-shadow',\n    transform: 'transform',\n  },\n  transitionTimingFunction: {\n    linear: 'linear',\n    in: 'cubic-bezier(0.4, 0, 1, 1)',\n    out: 'cubic-bezier(0, 0, 0.2, 1)',\n    'in-out': 'cubic-bezier(0.4, 0, 0.2, 1)',\n  },\n  transitionDuration: {\n    75: '75ms',\n    100: '100ms',\n    150: '150ms',\n    200: '200ms',\n    300: '300ms',\n    500: '500ms',\n    700: '700ms',\n    1000: '1000ms',\n  },\n  transitionDelay: {\n    75: '75ms',\n    100: '100ms',\n    150: '150ms',\n    200: '200ms',\n    300: '300ms',\n    500: '500ms',\n    700: '700ms',\n    1000: '1000ms',\n  },\n};\n\n\nTIP\n\nMore about TailwindCSS configuration\n\nThe designSystem is used to define the project's color palette, typographic\nscales (Typographic Scales or Type Scale), font list, breakpoints, border\nrounding values, etc. Since Modern.js borrows the design approach from Tailwind\nTheme and integrates with Tailwind CSS internally, designSystem is used in the\nsame way as Tailwind CSS Theme\n\nThe designSystem object contains the screens, colors and spacing properties, as\nwell as each customizable core plugin.\n\n\nScreens#\n\nThe responsive breakpoints in your project can be customized using screens: the\n\nconst designSystem = {\n  screens: {\n    sm: '640px',\n    md: '768px',\n    lg: '1024px',\n    xl: '1280px',\n  },\n};\n\n\nwhere the property name in the screens object is the screen name (used as a\nprefix for the adaptive utility variants generated by Tailwind CSS, e.g.\nmd:text-center) and the value is the min-width at which the breakpoint should\nstart.\n\nDefault breakpoints are inspired by common device resolutions: the\n\nconst designSystem = {\n  screens: {\n    sm: '640px',\n    // => @media (min-width: 640px) { ... }\n\n    md: '768px',\n    // => @media (min-width: 768px) { ... }\n\n    lg: '1024px',\n    // => @media (min-width: 1024px) { ... }\n\n    xl: '1280px',\n    // => @media (min-width: 1280px) { ... }\n  },\n};\n\n\nYou can use any name you like as a breakpoint property in your project: the\n\nconst designSystem = {\n  screens: {\n    tablet: '640px',\n    // => @media (min-width: 640px) { ... }\n\n    laptop: '1024px',\n    // => @media (min-width: 1024px) { ... }\n\n    desktop: '1280px',\n    // => @media (min-width: 1280px) { ... }\n  },\n};\n\n\nThese screen names are reflected in utilities, so text-center now looks like\nthis\n\n.text-center {\n  text-align: center;\n}\n\n@media (min-width: 640px) {\n  .tablet\\:text-center {\n    text-align: center;\n  }\n}\n\n@media (min-width: 1024px) {\n  .laptop\\:text-center {\n    text-align: center;\n  }\n}\n\n@media (min-width: 1280px) {\n  .desktop\\:text-center {\n    text-align: center;\n  }\n}\n\n\n\nMax-width breakpoints#\n\nTo use the max-width breakpoint instead of min-width, you can specify the screen\nas an object with the max attribute.\n\nconst designSystem = {\n  screens: {\n    xl: { max: '1279px' }\n    // => @media (max-width: 1279px) { ... }\n\n    lg: { max: '1023px' },\n    // => @media (max-width: 1023px) { ... }\n\n    md: { max: '767px' },\n    // => @media (max-width: 767px) { ... }\n\n    sm: { max: '639px' },\n    // => @media (max-width: 639px) { ... }\n  },\n};\n\n\nIf necessary, to create breakpoints with min-width and max-width definitions,\ne.g.\n\nconst designSystem = {\n  screens: {\n    sm: { min: '640px', max: '767px' }\n    md: { min: '768px', max: '1023px' }\n    lg: { min: '1024px', max: '1279px' }, lg: { min: '1024px', max: '1279px' },\n    xl: { min: '1280px' }\n  },\n};\n\n\n\nMultiple range breakpoints#\n\nSometimes it can be useful to apply a single breakpoint definition to multiple\nscopes.\n\nFor example, suppose you have a sidebar and want the breakpoint to be based on\nthe width of the content area rather than the entire viewport. You can simulate\nthis situation by using a smaller breakpoint style when the sidebar is visible\nand the content area is narrowed: the\n\nconst designSystem = {\n  screens: {\n    sm: '500px',\n    md: [\n      // Sidebar appears at 768px, so revert to `sm:` styles between 768px\n      // and 868px, after which the main content area is wide enough again to\n      // apply the `md:` styles.\n      { min: '668px', max: '767px' }\n      { min: '868px' }, { min: '868px' },\n    ],\n    lg: '1100px',\n    xl: '1400px',\n  },\n};\n\n\n\nCustom media queries#\n\nIf a fully customizable media query is required for a breakpoint, an object with\nthe raw attribute can be used.\n\nconst designSystem = {\n  extend: {\n    screens: {\n      portrait: { raw: '(orientation: portrait)' },\n      // => @media (orientation: portrait) { ... }\n    },\n  },\n};\n\n\n\nPrint styles#\n\nThe raw option may be particularly useful if you need to apply different styles\nto printing.\n\nAll that needs to be done is to add a print under designSystem.extend.screens.\n\n``js const designSystem = { extend: { screens: { print: { raw: 'print' }, // =>\n@media print { ... } }, }, };\n\n\nThen, a class such as ``print:text-black`` can be used to specify a style that is applied only when someone tries to print a page: ``\n\n```html\n\n\n  \n\n\n\n\nDark Mode#\n\nraw 选项可以用于实现 “暗模式” 屏幕：\n\nconst designSystem = {\n  extend: {\n    screens: {\n      dark: { raw: '(prefers-color-scheme: dark)' },\n      // => @media (prefers-color-scheme: dark) { ... }\n    },\n  },\n};\n\n\n然后，您可以使用 dark: 前缀在暗模式下为元素设置不同的样式：\n\n\n  \n\n\n\n请注意，由于这些 screen variants 是在 Tailwind CSS 中实现的，因此无法使用这种方法将断点与暗模式结合使用 ，例如\nmd:dark:text-gray-300 将不起作用。\n\n\nColors#\n\ncolors 属性可让您自定义项目的全局调色板。\n\nconst designSystem = {\n  colors: {\n    transparent: 'transparent',\n    black: '#000',\n    white: '#fff',\n    gray: {\n      100: '#f7fafc',\n      // ...\n      900: '#1a202c',\n    },\n\n    // ...\n  },\n};\n\n\nBy default, these colors are inherited by the backgroundColor, textColor and\nborderColor core plugins.\n\nTo learn more, you can check out: Customizing Colors.\n\n\nSpacing#\n\nThe global spacing and scaling of items can be customized using the space\nattribute: the\n\nconst designSystem = {\n  spacing: {\n    px: '1px',\n    0: '0',\n    1: '0.25rem',\n    2: '0.5rem',\n    3: '0.75rem',\n    4: '1rem',\n    5: '1.25rem',\n    6: '1.5rem',\n    8: '2rem',\n    10: '2.5rem',\n    12: '3rem',\n    16: '4rem',\n    20: '5rem',\n    24: '6rem',\n    32: '8rem',\n    40: '10rem',\n    48: '12rem',\n    56: '14rem',\n    64: '16rem',\n  },\n};\n\n\nBy default, these values are inherited by the padding, margin, negativeMargin,\nwidth and height core plugins.\n\nTo learn more, see Customizing Spacing.\n\n\nCore plugins#\n\nThe rest of the theme section is used to configure the values available for each\ncore plugin.\n\nFor example, the borderRadius property allows you to customize the ``utilities`\nthat will generate the rounded corners.\n\n``js const designSystem = { borderRadius: { none: '0', sm: '.125rem', default:\n'.25rem', lg: '.5rem', full: '9999px', }, };\n\n\n** The attribute name determines the suffix of the generated class, and the value determines the value of the actual CSS declaration. **\nThe example ``borderRadius`` configuration above will generate the following CSS classes.\n\n```css\n.rounded-none { border-radius: 0 }\n.rounded-sm { border-radius: .125rem }\n.rounded { border-radius: .25rem }\n.rounded-lg { border-radius: .5rem }\n.rounded-full { border-radius: 9999px }\n\n\nYou will notice that the rounded class is created without the suffix in the\ntheme configuration using the default attribute. This is a common convention in\nTailwind CSS supported by many (though not all) of the core plugins.\n\nTo learn more about customizing a specific core plugin, please visit the\ndocumentation for that plugin.\n\n\nCustomizing the default configuration#\n\nOut of the box, your project will automatically inherit values from the default\ntheme configuration. If you want to customize the default theme, there are\nseveral different options depending on the goal.\n\n\nOverride the default configuration#\n\nTo override the options in the default configuration, add the properties to be\noverridden to designSystem at\n\n\n\nconst designSystem = {\n  // Replaces all of the default `opacity` values\n  opacity: {\n    0: '0',\n    20: '0.2',\n    40: '0.4',\n    60: '0.6',\n    80: '0.8',\n    100: '1',\n  },\n};\n\nexport default defineConfig({\n  designSystem,\n});\n\n\nThis will completely replace the default property configuration, so in the above\nexample, the default opacity utilities will not be generated.\n\nAny properties you do not provide will be inherited from the default theme, so\nin the example above, the default theme configuration for color, spacing, border\nrounding, background position, etc. will be retained.\n\n\nExtending the default configuration#\n\nIf you want to keep the default values of the theme options but add new values,\nadd the extensions under the designSystem.extend property.\n\nFor example, if you want to add an additional breakpoint but keep the existing\none, you can extend the screens property with.\n\n\n\nconst designSystem = {\n  extend: {\n    // Adds a new breakpoint in addition to the default breakpoints\n    screens: {\n      '2xl': '1440px',\n    },\n  },\n};\n\nexport default defineConfig({\n  designSystem,\n});\n\n\nYou can certainly override some parts of the default theme and extend other\nparts of the default theme in the same configuration: the\n\n\n\nconst designSystem = {\n  opacity: {\n    0: '0',\n    20: '0.2',\n    40: '0.4',\n    60: '0.6',\n    80: '0.8',\n    100: '1',\n  },\n  extend: {\n    screens: {\n      '2xl': '1440px',\n    },\n  },\n};\n\nexport default defineConfig({\n  designSystem,\n});\n\n\n\nReferencing other values#\n\nIf you need to reference another value in the configuration, you can do so by\nproviding a closure function instead of a static value. The function will\nreceive the theme() function as an argument, and you can use this function to\nfind other values in the configuration using a dot representation.\n\nFor example, you can generate fill utilities for each color in the palette by\nreferring to theme('colors') on the fill configuration.\n\n\n\nconst designSystem = {\n  colors: {\n    // ...\n  },\n  fill: theme => theme('colors'),\n};\n\nexport default defineConfig({\n  designSystem,\n});\n\n\nThe theme() function tries to find the value you are looking for from an already\nfully merged configuration object, so it can reference your own custom settings\nas well as the default theme value. It also works recursively, so as long as\nthere is a static value at the end of the chain, it can resolve the value you\nare looking for.\n\nReference to the default configuration\n\nIf for any reason you want to reference a value in the default configuration,\nyou can import it from tailwindcss/defaultTheme. A useful example would be to\nadd one of the fonts provided by the default configuration to.\n\n\n\nconst defaultTheme = require('tailwindcss/defaultTheme');\n\nconst designSystem = {\n  extend: {\n    fontFamily: {\n      sans: ['Lato', ... .defaultTheme.fontFamily.sans],\n    },\n  },\n};\n\nexport default defineConfig({\n  designSystem,\n});\n\n\n\nDisabling the entire core plugin#\n\nIf you don't want to generate any classes for a core plugin, it's better to set\nthe plugin to false in the corePlugins configuration, rather than providing an\nempty object for the property in the configuration: ``\n\n// Don't assign an empty object in your theme configuration\n\nconst designSystem = {\n  opacity: {},\n};\n\n// Do disable the plugin in your corePlugins configuration\nconst designSyttem = {\n  corePlugins: {\n    opacity: { false,\n  },\n};\n\n\nThe end result is the same, but since many core plugins don't expose any\nconfiguration, it's best to keep it consistent by only disabling them with\ncorePlugins anyway.\n\n\nAdding your own key#\n\nIn many cases it may be useful to add your own properties to the configuration\nobject.\n\nOne example is to add new properties for multiplexing between multiple core\nplugins. For example, you can extract a positions object that both the\nbackgroundPosition and objectPosition plugins can refer to.\n\nconst designSystem = {\n  positions: {\n    bottom: 'bottom',\n    center: 'center',\n    left: 'left',\n    'left-bottom': 'left bottom',\n    'left-top': 'left top',\n    right: 'right',\n    'right-bottom': 'right bottom',\n    'right-top': 'right top',\n    top: 'top',\n  },\n  backgroundPosition: theme => theme('positions'),\n  objectPosition: theme => theme('positions'),\n};\n\n\nAnother example is to add a new property to a custom plugin for referencing. For\nexample, if you write a gradient plugin for your project, you can add a gradient\nproperty to the theme object referenced by that plugin.\n\n\n\nconst designSystem = {\n  gradients: theme => ({\n    'blue-green': [theme('colors.blue.500'), theme('colors.green.500')],\n    'purple-blue': [theme('colors.purple.500'), theme('colors.blue.500')],\n    // ...\n  }),\n};\n\nexport default defineConfig({\n  designSystem,\n  buildConfig: {\n    style: {\n      postcss: {\n        plugins: [require('. /plugins/gradients')],\n      },\n    },\n  },\n});\n\n\n\nConfiguration references#\n\nAll properties in the configuration object, except screens, colors and spacing,\nare mapped to the core plugins of Tailwind CSS. Since many plugins are\nresponsible for CSS properties that accept only static sets of values (e.g.,\ne.g., float), please note that not every plugin has a corresponding property in\nthe theme object.\n\nAll of these properties can also be used under the designSystem.extend property\nto extend the default theme.\n\nFor more information about what all the properties do, check out this link.","frontmatter":{"sidebar_position":3},"_filepath":"/Users/bytedance/github/targeral/modern-js/packages/document/module-doc/docs/en/api/config/design-system.md","_relativePath":"en/api/config/design-system.md"},{"id":3,"title":"dev","routePath":"/module-tools/en/api/config/dev","lang":"en","toc":[{"text":"storybook","id":"storybook","depth":2,"charIndex":178},{"text":"storybook.webpack","id":"storybookwebpack","depth":3,"charIndex":436},{"text":"Configure Manager App","id":"configure-manager-app","depth":4,"charIndex":817},{"text":"storybook.webpackChain","id":"storybookwebpackchain","depth":3,"charIndex":1190}],"domain":"","content":"#\n\nThis section describes all configuration of Module Tools related to debugging\ntools.\n\nexport default {\n  dev: {\n    storybook: {\n      /* Storybook Config */\n    },\n  },\n};\n\n\n\nstorybook#\n\nRequirements:\n\n * Turn on Storybook debugging or install the @modern-js/plugin-storybook\n   plugin.\n * Register the @modern-js/plugin-storybook plugin。\n\n> For more information on how to enable Storybook debugging, please refer\n> to：\"Storybook\"\n\n\nstorybook.webpack#\n\n * Type: object | Function | undefined\n * Default: undefined\n\nexport default {\n  dev: {\n    storybook: {\n      webpack(config) {\n        return config;\n      },\n    },\n  },\n};\n\n\nYou can modify the webpack configuration of the Storybook Preview-iframe via\ndev.storybook.webpack. The usage can be found in the tools.webpack configuration\nof Modern.js Builder.\n\n\n\nConfigure Manager App#\n\nFor the webpack configuration of the Storybook Manager app section, you can\nconfigure it by adding the ./config/storybook/main.js file to configure it.\n\n// ./config/storybook/main.js\n\nmodule.exports = {\n  // it controls the Storybook manager app\n  managerWebpack: async (config, options) => {\n    // update config here\n    return config;\n  },\n};\n\n\n\nstorybook.webpackChain#\n\n * Type: Function | undefined\n * Default: undefined\n\nexport default {\n  dev: {\n    storybook: {\n      webpackChain(chain) {\n        return chain;\n      },\n    },\n  },\n};\n\n\nYou can modify the webpack configuration of the Storybook Preview-iframe via\ndev.storybook.webpackChain. You can refer to Modern.js Builder's\ntools.webpackChain configuration for how to use it.","frontmatter":{"sidebar_position":3},"_filepath":"/Users/bytedance/github/targeral/modern-js/packages/document/module-doc/docs/en/api/config/dev.md","_relativePath":"en/api/config/dev.md"},{"id":4,"title":"plugins","routePath":"/module-tools/en/api/config/plugins","lang":"en","toc":[{"text":"Plugin Execution Order","id":"plugin-execution-order","depth":2,"charIndex":136},{"text":"Developing Plugins","id":"developing-plugins","depth":2,"charIndex":576},{"text":"Example","id":"example","depth":2,"charIndex":672},{"text":"Using Plugins from npm","id":"using-plugins-from-npm","depth":3,"charIndex":683},{"text":"Using Local Plugins","id":"using-local-plugins","depth":4,"charIndex":890},{"text":"Plugin Configuration","id":"plugin-configuration","depth":3,"charIndex":1074}],"domain":"","content":"#\n\nThis chapter describes the configuration of the registered Module Tools plugin.\n\n * Type: ModuleToolsPlugin[]\n * Default: undefined\n\n\nPlugin Execution Order#\n\nBy default, custom plugins are executed in the order specified in the plugins\narray. The execution of built-in plugins provided by Module Tools happens before\nthe execution of custom plugins.\n\nWhen plugins use fields that control the execution order, such as pre and post,\nthe execution order is adjusted based on the declared fields. For more\ninformation, please refer to the Relationship Between Plugins guide.\n\n\nDeveloping Plugins#\n\nTo learn how to write plugins, please refer to the Plugin Writing Guide.\n\n\nExample#\n\n\nUsing Plugins from npm#\n\nTo use plugins from npm, you need to install them using a package manager and\nimport them in your configuration file.\n\n\n\nexport default defineConfig({\n  plugins: [myPlugin()],\n});\n\n\nUsing Local Plugins#\n\nTo use plugins from a local code repository, you can directly import them using\na relative path.\n\n\n\nexport default defineConfig({\n  plugins: [myPlugin()],\n});\n\n\n\nPlugin Configuration#\n\nIf a plugin provides custom configuration options, you can pass the\nconfiguration through the plugin function's parameters.\n\n\n\nexport default defineConfig({\n  plugins: [\n    myPlugin({\n      foo: 1,\n      bar: 2,\n    }),\n  ],\n});\n","frontmatter":{"sidebar_position":4},"_filepath":"/Users/bytedance/github/targeral/modern-js/packages/document/module-doc/docs/en/api/config/plugins.md","_relativePath":"en/api/config/plugins.md"},{"id":5,"title":"testing","routePath":"/module-tools/en/api/config/testing","lang":"en","toc":[{"text":"jest","id":"jest","depth":2,"charIndex":133},{"text":"transformer","id":"transformer","depth":2,"charIndex":736}],"domain":"","content":"#\n\nThis chapter describes the test-related configuration\n\nTIP\n\nYou need to enable the unit testing feature with pnpm run new first.\n\n\njest#\n\n * Type: object | Function\n * Default: {}\n\nThe configuration corresponding to Jest, when of type object, can be configured\nwith all the underlying configurations supported by Jest .\n\n\n\nexport default defineConfig({\n  testing: {\n    jest: {\n      testTimeout: 10000,\n    },\n  },\n});\n\n\nWhen the value is of type Function, the default configuration is passed as the\nfirst parameter and a new Jest configuration object needs to be returned.\n\n\n\nexport default defineConfig({\n  testing: {\n    jest: options => {\n      return {\n        ... . options,\n        testTimeout: 10000\n      }\n    }\n  }\n});\n\n\n\ntransformer#\n\n * Type: 'babel-jest' | 'ts-jest'\n * Default: 'babel-jest'\n\nConfigure the compilation tool for the source code when executing tests:\nbabel-jest or ts-jest. The default is babel-jest.\n\nINFO\n\nbabel-jest can also compile TS files without type errors, so use ts-jest if you\nneed to check the TS type when running tests.","frontmatter":{"sidebar_position":5},"_filepath":"/Users/bytedance/github/targeral/modern-js/packages/document/module-doc/docs/en/api/config/testing.md","_relativePath":"en/api/config/testing.md"},{"id":6,"title":"Overview","routePath":"/module-tools/en/api/","lang":"en","toc":[],"domain":"","content":"#","frontmatter":{"overview":true,"sidebar_label":"Overview","sidebar_position":1},"_filepath":"/Users/bytedance/github/targeral/modern-js/packages/document/module-doc/docs/en/api/index.md","_relativePath":"en/api/index.md"},{"id":7,"title":"Plugin Hooks","routePath":"/module-tools/en/api/plugin-api/plugin-hooks","lang":"en","toc":[{"text":"build hooks","id":"build-hooks","depth":2,"charIndex":424},{"text":"beforeBuild","id":"beforebuild","depth":3,"charIndex":586},{"text":"beforeBuildTask","id":"beforebuildtask","depth":3,"charIndex":1223},{"text":"afterBuildTask","id":"afterbuildtask","depth":3,"charIndex":1695},{"text":"afterBuild","id":"afterbuild","depth":3,"charIndex":2099},{"text":"buildPlatform hooks","id":"buildplatform-hooks","depth":2,"charIndex":2554},{"text":"registerBuildPlatform","id":"registerbuildplatform","depth":3,"charIndex":3053},{"text":"beforeBuildPlatform","id":"beforebuildplatform","depth":3,"charIndex":3775},{"text":"buildPlatform","id":"buildplatform","depth":3,"charIndex":4499},{"text":"afterBuildPlatform","id":"afterbuildplatform","depth":3,"charIndex":4994},{"text":"Dev Hooks","id":"dev-hooks","depth":2,"charIndex":5698},{"text":"registerDev.","id":"registerdev","depth":3,"charIndex":6173},{"text":"beforeDev","id":"beforedev","depth":3,"charIndex":7283},{"text":"(before|after)DevMenu","id":"(before|after)devmenu","depth":3,"charIndex":7885},{"text":"beforeDevTask","id":"beforedevtask","depth":3,"charIndex":9066},{"text":"afterDev","id":"afterdev","depth":3,"charIndex":9636}],"domain":"","content":"#\n\nThis chapter describes the lifecycle hooks supported by module-tools.\n\nCurrently there are two main types of lifecycle hooks.\n\n * Build hooks: triggered only when the build command is executed to build the\n   source code product.\n * buildPlatform hook: triggered only when the build --platform command is\n   executed to generate other build products.\n * dev hooks: hooks that are triggered when running the dev command.\n\n\nbuild hooks#\n\nThe following Hooks are triggered in order when the build command is executed.\n\n * beforeBuild\n * beforeBuildTask\n * afterBuildTask\n * afterBuild\n\n\nbeforeBuild#\n\nTriggered before the execution of the overall build process.\n\nexport const myPlugin = (): CliPlugin => ({\n  name: 'my-plugin',\n\n  setup() {\n    return {\n      beforeBuild(options: Options): Return {\n        return options.config;\n      }\n    }\n  },\n});\n\n\nParameters and return value types.\n\ntype Options = { options: { config: BuildConfig; cliOptions: BuildCommandOptions } }\n\nexport interface BuildCommandOptions {\n  config: string;\n  clear?: boolean;\n  dts?: boolean;\n  platform?: boolean | string[];\n  tsconfig: string;\n  watch?: boolean;\n}\n\ntype Return = BuildConfig;\n\n\n> BuildConfig type reference API configuration\n\n\nbeforeBuildTask#\n\nBased on the build configuration, Module Tools will split the overall build into\nmultiple sub-build tasks. The Hook will be triggered before each build subtask.\n\nexport const myPlugin = (): CliPlugin => ({\n  name: 'my-plugin',\n\n  setup() {\n    return {\n      beforeBuildTask(config: BaseBuildConfig): BaseBuildConfig {\n        return config;\n      }\n    }\n  },\n});\n\n\nParameters and return value types.\n\nBaseBuildConfig type reference API configuration\n\n\nafterBuildTask#\n\nTriggered after the end of each build subtask.\n\nexport const myPlugin = (): CliPlugin => ({\n  name: 'my-plugin',\n\n  setup() {\n    return {\n      afterBuildTask(options: BuildTaskResult): void {\n        // ...\n      }\n    }\n  },\n});\n\n\nParameters and return value types.\n\nexport interface BuildTaskResult {\n  status: 'success' | 'fail';\n  message?: string;\n  config: BaseBuildConfig;\n}\n\n\n\nafterBuild#\n\nTriggered after the end of the overall build process.\n\nexport const myPlugin = (): CliPlugin => ({\n  name: 'my-plugin',\n\n  setup() {\n    return {\n      afterBuild(options: BuildResult): void {\n        // ...\n      }\n    }\n  },\n});\n\n\nParameters and return value types.\n\nexport interface BuildResult {\n  status: 'success' | 'fail';\n  message?: string;\n  config: BuildConfig;\n  commandOptions: BuildCommandOptions;\n  totalDuration: number;\n}\n\n\n\nbuildPlatform hooks#\n\nmodule-tools also provides the build --platform command to perform specific\nbuild tasks.\n\nFor example, after installing the Storybook plugin, you can run build --platform\nor build --platform storybook to perform Storybook build tasks. This is because\nthe Storybook plugin is based on the buildPlatform Hooks.\n\nHooks are triggered in the following order after executing build --platform.\n\n * registerBuildPlatform\n * beforeBuildPlatform\n * buildPlatform\n * afterBuildPlatform\n\n\nregisterBuildPlatform#\n\nGets information about the tasks that need to be run when executing the build\n--platform command.\n\nexport const myPlugin = (): CliPlugin => ({\n  name: 'my-plugin',\n\n  setup() {\n    return {\n      registerBuildPlatform(): RegisterBuildPlatformResult {\n        // ...\n        return {\n          platform: 'stroybook',\n          build() {\n            // run storybook logic\n          },\n        }, };\n      },\n    };\n  },\n});\n\n\nTypes of parameters entered and returned.\n\nexport interface RegisterBuildPlatformResult {\n  platform: string | string[];\n  build: (\n    currentPlatform: string, // the currently running platform build task\n    context: { isTsProject: boolean },\n  ) => void | Promise;\n}\n\n\n\nbeforeBuildPlatform#\n\nTriggers all registered build tasks when the build --platform command is\nexecuted. beforeBuildPlatform will be triggered before the execution of the\noverall build task.\n\nexport const myPlugin = (): CliPlugin => ({\n  name: 'my-plugin',\n\n  setup() {\n    return {\n      beforeBuildPlatform(platforms: RegisterBuildPlatformResult[]): void {\n        console.info(`have ${platforms.length} platform tasks`);\n      },\n    };\n  },\n});\n\n\nTypes of parameters entered and returned.\n\nexport interface RegisterBuildPlatformResult {\n  platform: string | string[];\n  build: (\n    currentPlatform: string, // the currently running platform build task\n    context: { isTsProject: boolean },\n  ) => void | Promise;\n}\n\n\n\nbuildPlatform#\n\nWhen the build --platform command is executed, all registered build tasks will\nbe triggered. buildPlatform will be triggered before each build task is\nexecuted.\n\nexport const myPlugin = (): CliPlugin => ({\n  name: 'my-plugin',\n\n  setup() {\n    return {\n      buildPlatform({ platform }: Options): void {\n        console.info(`current task is ${platform}`);\n      },\n    };\n  },\n});\n\n\nTypes of parameters entered and returned.\n\nexport interface Options {\n  platform: string;\n}\n\n\n\nafterBuildPlatform#\n\nWhen the build --platform command is executed, all registered build tasks will\nbe triggered. afterBuildPlatform will be triggered after the overall platform\nbuild task is finished.\n\nexport const myPlugin = (): CliPlugin => ({\n  name: 'my-plugin',\n\n  setup() {\n    return {\n      afterBuildPlatform(result: BuildPlatformResult): void {\n        if (result.status === 'success') {\n          console.info(`all platform build task success`);\n        } else {\n          console.error(result.message);\n        }\n      },\n    };\n  },\n});\n\n\nTypes of parameters entered and returned.\n\nexport interface BuildPlatformResult {\n  status: 'success' | 'fail';\n  message: string | Error | null;\n}\n\n\n\nDev Hooks#\n\nThe following Hooks are triggered in order when the dev command is executed.\n\n * registerDev: triggered when getting dev function information.\n * beforeDev: Triggered before starting the dev process as a whole.\n * beforeDevMenu: triggered before the dev list/menu appears.\n * afterDevMenu: triggered after dev list/menu option is selected.\n * beforeDevTask: Triggered before executing the dev task.\n * afterDev: Triggered at the end of the overall dev process.\n\n\nregisterDev.#\n\nRegister dev tool related data. Mainly contains.\n\n * the name of the dev tool\n * The name of the item displayed in the menu list and the corresponding value.\n * The definition of the dev subcommand.\n * Whether to execute the source code build before running the dev task\n * The function to execute the dev task.\n\nexport const myPlugin = (): CliPlugin => ({\n  name: 'my-plugin',\n\n  setup() {\n    return {\n      registerDev() {\n        return {\n          // Dev tool name\n          name: 'storybook',\n          // Menu content\n          menuItem: {\n            name: 'Storybook',\n            value: 'storybook',\n          },\n          // Defined dev subcommands\n          subCommands: ['storybook', 'story'],\n          async action() {\n            // dev logic\n          },\n        };\n      },\n    };\n  },\n});\n\n\nTypes of parameters entered and returned.\n\nexport interface DevToolData {\n  name: string;\n  subCommands?: string[];\n  menuItem?: {\n    name: string;\n    value: string;\n  };\n  action: (\n    options: { port?: string },\n    context: { isTsProject?: boolean },\n  ) => void | Promise;\n}\n\n\n\nbeforeDev#\n\nTriggered before the dev task is executed after all dev tool metadata has been\ncollected.\n\nexport const myPlugin = (): CliPlugin => ({\n  name: 'my-plugin',\n\n  setup() {\n    return {\n      beforeDev(metas: DevToolData[]) {\n        console.info(`have ${metas.length} dev tools`);\n      },\n    };\n  },\n});\n\n\nTypes of parameters entered and returned.\n\nexport interface DevToolData {\n  name: string;\n  subCommands?: string[];\n  menuItem?: {\n    name: string;\n    value: string;\n  };\n  action: (\n    options: { port?: string },\n    context: { isTsProject?: boolean },\n  ) => void | Promise;\n}\n\n\n\n(before|after)DevMenu#\n\nbeforeDevMenu is triggered before the dev list/menu appears. Receives inquirer\nquestion as argument. Default value is.\n\nconst question = [\n  {\n    name: 'choiceDevTool',\n    message: 'Select dev tool',\n    type: 'list',\n    // Registered dev messages\n    choices,\n  },\n];\n\n\nafterDevMenu Triggered after selecting dev list/menu options.\n\nexport const myPlugin = (): CliPlugin => ({\n  name: 'my-plugin',\n\n  setup() {\n    return {\n      beforeDevMenu(questions) {\n        questions[0].message += '!' ;\n        return questions; // required\n      },\n      afterDevMenu(options: Options) {\n        console.info(`choise ${options.result.choiceDevTool} dev tools`);\n      }\n    };\n  },\n});\n\n\nTypes of parameters entered and returned.\n\nexport type { QuestionCollection } from 'inquirer';\n\nexport interface Options {\n  result: PromptResult;\n  devTools: DevToolData[];\n}\n\nexport type PromptResult = { choiceDevTool: string }\nexport interface DevToolData {\n  name: string;\n  subCommands?: string[];\n  menuItem?: {\n    name: string;\n    value: string;\n  };\n  action: (\n    options: { port?: string },\n    context: { isTsProject?: boolean },\n  ) => void | Promise;\n}\n\n\n\nbeforeDevTask#\n\nTriggered before the dev task is executed.\n\nexport const myPlugin = (): CliPlugin => ({\n  name: 'my-plugin',\n\n  setup() {\n    return {\n      beforeDevTask(currentDevData: DevToolData) {\n        console.info(`${currentDevData.name} running`);\n      },\n    };\n  },\n});\n\n\nTypes of parameters entered and returned.\n\nexport interface DevToolData {\n  name: string;\n  subCommands?: string[];\n  menuItem?: {\n    name: string;\n    value: string;\n  };\n  action: (\n    options: { port?: string },\n    context: { isTsProject?: boolean },\n  ) => void | Promise;\n}\n\n\n\nafterDev#\n\nTriggered when the dev task process is interrupted.\n\nexport const myPlugin = (): CliPlugin => ({\n  name: 'my-plugin',\n\n  setup() {\n    return {\n      afterDev() {\n        console.info(`exit!`);\n      },\n    };\n  },\n});\n","frontmatter":{},"_filepath":"/Users/bytedance/github/targeral/modern-js/packages/document/module-doc/docs/en/api/plugin-api/plugin-hooks.md","_relativePath":"en/api/plugin-api/plugin-hooks.md"},{"id":8,"title":"Handle static resource files","routePath":"/module-tools/en/guide/advance/asset","lang":"en","toc":[{"text":"Default behavior","id":"default-behavior","depth":2,"charIndex":144}],"domain":"","content":"#\n\nThe module project will handle static resources used in the code. If\nconfiguration is required, then the buildConfig.asset API can be used.\n\n\nDefault behavior#\n\nBy default, module projects are processed for the following static resources:\n\n * '.svg'、'.png'、'.jpg'、'.jpeg'、'.gif'、'.webp'\n * '.ttf'、'.otf'、'.woff'、'.woff2'、'.eot'\n * '.mp3'、'.mp4'、'.webm'、'.ogg'、'.wav'、'.flac'、'.aac'、'.mov'\n\nFor the handling of static files, the module project currently supports the\nfollowing functions.\n\n * Set the static resource path to . /assets.\n * Files less than 10kb will be inlined into the code.\n\nLet us look at the following example:\n\nWhen wanting to modify the default behavior, the following API can be used:\n\n * asset.path: modify the output path of the static resource file.\n * asset.limit: modify the threshold value for inline static resource files.","frontmatter":{"sidebar_position":6},"_filepath":"/Users/bytedance/github/targeral/modern-js/packages/document/module-doc/docs/en/guide/advance/asset.mdx","_relativePath":"en/guide/advance/asset.mdx"},{"id":9,"title":"Build umd products","routePath":"/module-tools/en/guide/advance/build-umd","lang":"en","toc":[{"text":"Third-party dependency handling for umd products","id":"third-party-dependency-handling-for-umd-products","depth":2,"charIndex":484},{"text":"Changing the name of a global variable in a project","id":"changing-the-name-of-a-global-variable-in-a-project","depth":2,"charIndex":1500}],"domain":"","content":"#\n\nThe full name of umd is Universal Module Definition, and JS files in this format\ncan run in multiple runtime environments: the\n\n * Browser environment: module loading based on AMD specification\n * Node.js environment: module loading based on CommonJS\n * Other cases: mount the module on a global object.\n\nWe can therefore specify the build product of the project as an umd product in\nthe following way:\n\nexport default defineConfig({\n  buildConfig: {\n    format: 'umd',\n  },\n});\n\n\n\nThird-party dependency handling for umd products#\n\nIn the \"How to handle third-party dependencies\" chapter, we know that we can\ncontrol whether or not the project packages third-party dependencies via the\nautoExternals and externals APIs. So when building umd products, we can also use\nit like this:\n\nWe know from the above example that when using the autoExternal and externals\nAPIs.\n\n * In a Node.js environment, you can get the react dependency with\n   require('react').\n * In a browser environment, you can get the react dependency via global.react.\n\nHowever, in the browser environment, when getting third-party dependencies,\nglobal variable names are not necessarily identical to the dependency names, so\nyou have to use the buildConfig.umdGlobals API.\n\nAgain using the previous example, when the react dependency exists in the\nbrowser environment as a windows.React or global.React global variable, then:\n\nThe project can then run in the browser and use the React variables that exist\non the global object.\n\n\nChanging the name of a global variable in a project#\n\nWhen we package the following code into an umd product and run it in the\nbrowser, we can use the module via window.index.\n\nexport default () => {\n  console.info('hello world');\n};\n\n\n** By default, the name of the source file is used as the name of the module's\nglobal variable in the browser. **For the above example, the product would read\nas follows:\n\n(function (global, factory) {\n  if (typeof module === 'object' && typeof module.exports === 'object')\n    factory(exports);\n  else if (typeof define === 'function' && define.amd)\n    define(['exports'], factory);\n  else if (\n    (global = typeof globalThis !== 'undefined' ? globalThis : global || self)\n  )\n    factory((global.index = {}));\n})(this, function (exports) {\n  //...\n});\n\n\nIf you need to modify it, you need to use the buildConfig.umdModuleName API.\n\nWhen this API is used:\n\nexport default defineConfig({\n  buildConfig: {\n    format: 'umd',\n    umdModuleName: 'myLib',\n  },\n});\n\n\nThe construction products at this point are:\n\n(function (global, factory) {\n  if (typeof module === 'object' && typeof module.exports === 'object')\n    factory(exports);\n  else if (typeof define === 'function' && define.amd)\n    define(['exports'], factory);\n  else if (\n    (global = typeof globalThis !== 'undefined' ? globalThis : global || self)\n  )\n    factory((global.myLib = {}));\n})(this, function (exports) {\n  //...\n});\n","frontmatter":{"sidebar_position":5},"_filepath":"/Users/bytedance/github/targeral/modern-js/packages/document/module-doc/docs/en/guide/advance/build-umd.mdx","_relativePath":"en/guide/advance/build-umd.mdx"},{"id":10,"title":"Use the Copy Tools","routePath":"/module-tools/en/guide/advance/copy","lang":"en","toc":[{"text":"Understanding the Copy API","id":"understanding-the-copy-api","depth":2,"charIndex":174},{"text":"API Description","id":"api-description","depth":2,"charIndex":424},{"text":"不同场景使用示例","id":"不同场景使用示例","depth":2,"charIndex":1760},{"text":"将文件复制文件","id":"将文件复制文件","depth":3,"charIndex":1772},{"text":"将文件复制到目录","id":"将文件复制到目录","depth":3,"charIndex":2116},{"text":"从目录复制到目录","id":"从目录复制到目录","depth":3,"charIndex":2454},{"text":"从目录到文件","id":"从目录到文件","depth":3,"charIndex":2848},{"text":"使用 Glob","id":"使用-glob","depth":3,"charIndex":3253}],"domain":"","content":"#\n\nThe Module Project provides the Copy utility for copying already existing\nindividual files or entire directories into the product directory. Next we learn\nhow to use it.\n\n\nUnderstanding the Copy API#\n\nWe can use the Copy tool via the buildConfig.copy API, which contains the\nfollowing two main configurations.\n\n * patterns\n * options\n\nIt is recommended to spend some time getting to know them before you start\nlearning.\n\n\nAPI Description#\n\ncopy.patterns 用于寻找复制的文件以及配置输出的路径。\n\n其中 patterns.from 用于指定要复制的文件或者目录。它接收 Glob 形式字符串或具体路径。Glob 形式字符串是指 fast-glob\npattern-syntax。因此我们可以按照如下两种方式使用它：\n\nexport default defineConfig({\n  buildConfig: {\n    copy: {\n      patterns: [\n        { from: './index.html', to: '' },\n        { from: './*.html', to: '' },\n      ],\n    },\n  },\n});\n\n\npatterns.context 一般和 patterns.from 配合使用，默认情况下它的值与 buildConfig.sourceDir\n相同，因此我们可以按照如下方式指定 src/data.json 文件为要复制的文件：\n\n> 默认情况下，buildConfig.sourceDir 为 src\n\nexport default defineConfig({\n  buildConfig: {\n    copy: {\n      patterns: [\n        { from: './data.json' to: ''},\n      ],\n    },\n  },\n});\n\n\n当指定的文件不在源码目录的时候，可以修改 context 配置。例如指定项目目录下的 temp/index.html 为要复制的文件：\n\n\n\nexport default defineConfig({\n  buildConfig: {\n    copy: {\n      patterns: [\n        {\n          from: './index.html',\n          context: path.join(__dirname, './temp')\n          to: '',\n        }\n      ],\n    },\n  },\n});\n\n\npatterns.to 用于指定复制文件的输出路径，默认情况下它的值为 buildConfig.outDir对应的值。因此我们按照如下方式将\nsrc/index.html 复制到 dist 目录下：\n\nexport default defineConfig({\n  buildConfig: {\n    copy: {\n      patterns: [{ from: './index.html' }],\n    },\n  },\n});\n\n\n当我们配置了 patterns.to 的时候：\n\n * 如果是相对路径，则该路径会相对于 buildConfig.outDir 计算出复制文件输出的绝对路径。\n * 如果是绝对路径，则会直接使用该值。\n\n最后 patterns.globOptions 用于配置寻找复制文件 globby 对象，其配置可参考：\n\n * globby.options\n\n\n不同场景使用示例#\n\n\n将文件复制文件#\n\nexport default defineConfig({\n  buildConfig: [\n    {\n      outDir: 'dist',\n      copy: {\n        patterns: [\n          /**\n           * copy file to file\n           */\n          {\n            from: './temp-1/a.png',\n            context: __dirname,\n            to: './temp-1/b.png',\n          },\n        ],\n      },\n    },\n  ],\n});\n\n\n\n将文件复制到目录#\n\nexport default defineConfig({\n  buildConfig: [\n    {\n      outDir: 'dist',\n      copy: {\n        patterns: [\n          /**\n           * copy file to dir\n           */\n          {\n            from: './temp-2/a.png',\n            context: __dirname,\n            to: './temp-2',\n          },\n        ],\n      },\n    },\n  ],\n});\n\n\n\n从目录复制到目录#\n\nexport default defineConfig({\n  buildConfig: [\n    {\n      outDir: 'dist',\n      copy: {\n        patterns: [\n          /**\n           * copy dir to dir\n           */\n          {\n            from: './temp-3/',\n            to: './temp-3',\n            context: __dirname,\n          },\n        ],\n        options: {\n          enableCopySync: true,\n        },\n      },\n    },\n  ],\n});\n\n\n\n从目录到文件#\n\nexport default defineConfig({\n  buildConfig: [\n    {\n      outDir: 'dist',\n      copy: {\n        patterns: [\n          /**\n           * copy dir to file\n           */\n          {\n            from: './temp-4/',\n            context: __dirname,\n            to: './temp-4/_index.html',\n          },\n        ],\n        options: {\n          enableCopySync: true,\n        },\n      },\n    },\n  ],\n});\n\n\n\n使用 Glob#\n\nexport default defineConfig({\n  buildConfig: [\n    {\n      outDir: 'dist',\n      copy: {\n        patterns: [\n          /**\n           * copy glob to dir\n           */\n          {\n            from: './*.html',\n            to: './temp-5',\n          },\n        ],\n        options: {\n          enableCopySync: true,\n        },\n      },\n    },\n    {\n      copy: {\n        patterns: [\n          /**\n           * copy glob to file\n           */\n          {\n            from: './*.html',\n            to: './temp-6/index.html',\n          },\n        ],\n        options: {\n          enableCopySync: true,\n        },\n      },\n    },\n  ],\n});\n","frontmatter":{"sidebar_position":3},"_filepath":"/Users/bytedance/github/targeral/modern-js/packages/document/module-doc/docs/en/guide/advance/copy.md","_relativePath":"en/guide/advance/copy.md"},{"id":11,"title":"How to handle third-party dependencies","routePath":"/module-tools/en/guide/advance/external-dependency","lang":"en","toc":[{"text":"Default handling of third-party dependencies","id":"default-handling-of-third-party-dependencies","depth":2,"charIndex":861},{"text":"Exclude specified third-party dependencies","id":"exclude-specified-third-party-dependencies","depth":2,"charIndex":1535}],"domain":"","content":"#\n\nGenerally, third-party dependencies required by a project can be installed via\nthe install command in the package manager. After the third-party dependencies\nare successfully installed, they will generally appear under dependencies and\ndevDependencies in the project package.json.\n\n{\n  \"dependencies\": {},\n  \"devDependencies\": {}\n}\n\n\nDependencies under \"dependencies\" are generally related to project code and\nbuilds, and if these third-party dependencies are declared under\n\"devDependencies\", then there will be missing dependencies in production\nenvironments.\n\nIn addition to \"dependencies\", \"peerDependencies\" can also declare dependencies\nthat are needed in the production environment, but it puts more emphasis on the\nexistence of these dependencies declared by \"peerDependencies\" in the project's\nruntime environment, similar to the plugin mechanism.\n\n\nDefault handling of third-party dependencies#\n\nBy default, third-party dependencies under \"dependencies\" and \"peerDependencies\"\nare not packaged in the module project**.\n\nThis is because when the npm package is installed, its \"dependencies\" will also\nbe installed. By not packaging \"dependencies\", you can reduce the size of the\npackage product.\n\nIf you need to package some dependencies, it is recommended to move them from\n\"dependencies\" to \"devDependencies\", which is equivalent to prebundle the\ndependencies and reduces the size of the dependency installation.\n\nIf you want to modify the default processing, you can use the following API.\n\n * buildConfig.autoExternal\n\n\nExclude specified third-party dependencies#\n\nWe mentioned above the use of the buildConfig.autoExternal API, and\nbuildConfig.externals can control which third-party dependencies to handle the\nproject's dependencies in a more granular way.\n\nFor example, when we need to leave only certain dependencies unpacked, we can\nconfigure it as follows.\n\n> In this case, it is likely that some dependencies are not suitable for\n> packaging. If this is the case, then you can handle it as follows.\n\nepxort default defineConfig({\n  buildConfig: {\n    autoExternal: false,\n    externals: ['pkg-1', /pkg-2/],\n  }\n});\n","frontmatter":{"sidebar_position":4},"_filepath":"/Users/bytedance/github/targeral/modern-js/packages/document/module-doc/docs/en/guide/advance/external-dependency.mdx","_relativePath":"en/guide/advance/external-dependency.mdx"},{"id":12,"title":"In-depth understanding of build","routePath":"/module-tools/en/guide/advance/in-depth-about-build","lang":"en","toc":[{"text":"In-depth understanding of buildConfig","id":"in-depth-understanding-of-buildconfig","depth":2,"charIndex":499},{"text":"Bundle and Bundleless","id":"bundle-and-bundleless","depth":3,"charIndex":540},{"text":"Relationship between input and sourceDir","id":"relationship-between-input-and-sourcedir","depth":3,"charIndex":1676},{"text":"Object type of input","id":"object-type-of-input","depth":4,"charIndex":2442},{"text":"sourceDir","id":"sourcedir","depth":4,"charIndex":2998},{"text":"Declaration Type Files","id":"declaration-type-files","depth":3,"charIndex":3389},{"text":"Turn off type generation","id":"turn-off-type-generation","depth":4,"charIndex":3490},{"text":"Build type files","id":"build-type-files","depth":4,"charIndex":3766},{"text":"Alias Conversion","id":"alias-conversion","depth":4,"charIndex":4472},{"text":"Some examples of the use of dts","id":"some-examples-of-the-use-of-dts","depth":4,"charIndex":5028},{"text":"buildConfig.define Usage for different scenarios","id":"buildconfigdefine-usage-for-different-scenarios","depth":3,"charIndex":5727},{"text":"Environment variable replacement","id":"environment-variable-replacement","depth":4,"charIndex":5892},{"text":"Global variable replacement","id":"global-variable-replacement","depth":4,"charIndex":6307},{"text":"Build process","id":"build-process","depth":2,"charIndex":6913},{"text":"Build errors","id":"build-errors","depth":2,"charIndex":7206}],"domain":"","content":"#\n\nIn the \"Basic Usage\" section, we already knew that you can modify the output\nproduct of a project through the buildConfig configuration. buildConfig not only\ndescribes some of the features of the product, but also provides some\nfunctionality for building the product.\n\nTIP\n\nIf you are not familiar with buildConfig, please read modify-output-product.\n\nIn this chapter we'll dive into the use of certain build configurations and\nunderstand what happens when the modern build command is executed.\n\n\nIn-depth understanding of buildConfig#\n\n\nBundle and Bundleless#\n\nSo first let's understand Bundle and Bundleless.\n\nA Bundle is a package of build products, which may be a single file or multiple\nfiles based on a certain code splitting strategy.\n\nBundleless, on the other hand, means that each source file is compiled and built\nseparately, but not packaged together. Each product file can be found with its\ncorresponding source code file. The process of Bundleless build can also be\nunderstood as the process of code conversion of source files only.\n\nThey have their own benefits.\n\n * Bundle can reduce the size of build products and also pre-package\n   dependencies to reduce the size of installed dependencies. Packaging\n   libraries in advance can speed up application project builds.\n * Bundleless maintains the original file structure and is more conducive to\n   debugging and tree shaking.\n\nWARNING\n\nBundleless is a single file compilation mode, so for type references and exports\nyou need to add the type field, e.g. import type { A } from '. /types\n\nIn buildConfig you can specify whether the current build task is Bundle or\nBundleless by using buildConfig.buildType.\n\n\nRelationship between input and sourceDir#\n\nbuildConfig.input is used to specify the file path or directory path where the\nsource code is read, and its default value differs between Bundle and Bundleless\nbuilds.\n\n * When buildType: 'bundle', input defaults to src/index.(j|t)sx?\n * When buildType: 'bundleless', input defaults to ['src']\n\nWARNING\n\nIt is recommended that you do not specify multiple source file directories\nduring a Bundleless build, as unintended results may occur. Bundleless builds\nwith multiple source directories are currently in an unstable stage.\n\nWe know from the defaults: Bundle builds can generally specify a file path as\nthe entry point to the build, while Bundleless builds are more expected to use\ndirectory paths to find source files.\n\nObject type of input#\n\nIn addition to setting input to an array, you can also set it to an object\nduring the Bundle build process. By using the object form, we can modify the\nname of the file that the build product outputs. So for the following example, .\n/src/index.ts corresponds to the path of the build product file as .\n/dist/main.js.\n\n\n\nexport default defineConfig({\n  buildConfig: {\n    input: {\n      main: ['./src/index.ts'],\n    },\n    outDir: './dist',\n  },\n});\n\n\nThe Bundleless build process also supports such use, but it is not recommended.\n\nsourceDir#\n\nsourceDir is used to specify the source code directory, which is related to\nboth.\n\n * type file generation\n * outbase for specifying the build process\n\nIn general:\n\n * During the Bundleless build process, the values of sourceDir and input should\n   be the same, and their default values are both src.\n * It is rarely necessary to use sourceDir during the Bundle build process.\n\n\nDeclaration Type Files#\n\nThe buildConfig.dts configuration is mainly used for type file generation.\n\nTurn off type generation#\n\nType generation is turned on by default, if you need to turn it off, you can\nconfigure it as follows:\n\n\n\nexport default defineConfig({\n  buildConfig: {\n    dts: false,\n  },\n});\n\n\nTIP\n\nThe build speed is generally improved by closing the type file.\n\nBuild type files#\n\nWith buildType: 'bundleless', type files are generated using the project's tsc\ncommand to complete production.\n\nThe module engineering solution also supports packaging of type files, although\ncare needs to be taken when using this feature.\n\n * Some third-party dependencies have incorrect syntax that can cause the\n   packaging process to fail. So in this case, you need to exclude such\n   third-party packages manually with buildConfig.externals.\n * It is not possible to handle the case where the type file of a third-party\n   dependency points to a .ts file. For example, the package.json of a\n   third-party dependency contains something like this: {\"types\": \".\n   /src/index.ts\"}.\n\nAlias Conversion#\n\nDuring the Bundleless build process, if an alias appears in the source code,\ne.g.\n\n\n\n\nNormally, product type files generated with tsc will also contain these aliases.\nHowever, Module Tools will convert the aliases in the type file generated by tsc\nto:\n\n * Alias conversion is possible for code of the form ``.\n * Aliasing is possible for code of the form export { utils } from\n   '@common/utils'.\n\nHowever, there are some cases that cannot be handled at this time.\n\n * Output types of the form Promise cannot be converted at this time.\n\nSome examples of the use of dts#\n\nGeneral usage:\n\n\n\nexport default defineConfig({\n  // The output path of the packaged type file at this point is `./dist/types`\n  buildConfig: {\n    buildType: 'bundle',\n    dts: {\n      tsconfigPath: './other-tsconfig.json',\n      distPath: './types',\n    },\n    outDir: './dist',\n  },\n});\n\n\nFor the use of dts.only:\n\n\n\nexport default defineConfig({\n  // At this moment the type file is not packaged and the output path is `./dist/types`\n  buildConfig: [\n    {\n      buildType: 'bundle',\n      dts: false,\n      outDir: './dist',\n    },\n    {\n      buildType: 'bundleless',\n      dts: {\n        only: true,\n      },\n      outDir: './dist/types',\n    },\n  ],\n});\n\n\n\nbuildConfig.define Usage for different scenarios#\n\nbuildConfig.define functions somewhat similar to webpack.DefinePlugin. A few\nusage scenarios are described here.\n\nEnvironment variable replacement#\n\n\nexport default defineConfig({\n  buildConfig: {\n    define: {\n      'process.env.VERSION': JSON.stringify(process.env.VERSION || '0.0.0'),\n    },\n  },\n});\n\n\nWith the above configuration, we can put the following code.\n\n// pre-compiler code\nconsole.log(process.env.VERSION);\n\n\nWhen executing VERSION=1.0.0 modern build, the conversion is:\n\n// compiled code\nconsole.log('1.0.0');\n\n\nGlobal variable replacement#\n\n\nexport default defineConfig({\n  buildConfig: {\n    define: {\n      VERSION: JSON.stringify(require('. /package.json').version || '0.0.0'),\n    },\n  },\n});\n\n\nWith the above configuration, we can put the following code.\n\n// pre-compile code\nconsole.log(VERSION);\n\n\nConvert to:\n\n// post-compile code\nconsole.log('1.0.0');\n\n\nNote, however: If the project is a TypeScript project, then you may need to add\nthe following to the .d.ts file in the project source directory.\n\n> If the .d.ts file does not exist, then you can create it manually.\n\ndeclare const YOUR_ADD_GLOBAL_VAR;\n\n\n\nBuild process#\n\nWhen the modern build command is executed, the\n\n * Clear the products directory according to buildConfig.outDir.\n * Compile js/ts source code to generate the JS build product for\n   Bundle/Bundleless.\n * Generate Bundle/Bundleless type files using tsc.\n * Handle Copy tasks.\n\n\nBuild errors#\n\nWhen a build error occurs, based on the information learned above, it is easy to\nunderstand what error appears in the terminal.\n\nErrors reported for js or ts builds:\n\nerror  ModuleBuildError:\n\n╭───────────────────────╮\n│ bundle failed:        │\n│  - format is \"cjs\"    │\n│  - target is \"esnext\" │\n╰───────────────────────╯\n\nDetailed Information:\n\n\nErrors reported for the type file generation process:\n\nerror   ModuleBuildError:\n\nbundle DTS failed:\n\n\nFor js/ts build errors, we can tell from the error message.\n\n * By 'bundle failed:' to determine if the error is reported for a Bundle build\n   or a Bundleless build?\n * What is the format of the build process?\n * What is the target of the build process?\n * The specific error message.","frontmatter":{"sidebar_position":1},"_filepath":"/Users/bytedance/github/targeral/modern-js/packages/document/module-doc/docs/en/guide/advance/in-depth-about-build.md","_relativePath":"en/guide/advance/in-depth-about-build.md"},{"id":13,"title":"In-depth understanding of the dev command","routePath":"/module-tools/en/guide/advance/in-depth-about-dev-command","lang":"en","toc":[{"text":"The overall flow of the command run","id":"the-overall-flow-of-the-command-run","depth":2,"charIndex":90},{"text":"Extending the dev command","id":"extending-the-dev-command","depth":2,"charIndex":795}],"domain":"","content":"#\n\nThe dev command provided by the module project is mainly used for debugging the\ncode.\n\n\nThe overall flow of the command run#\n\n 1. When the dev command is executed, Module Tools starts looking for debugging\n    tools or tasks that can be executed. A debugging tool or task is a Module\n    Tools debugging tool plugin like Storybook.\n 2. When a debugging tool is found, it is executed immediately.\n 3. When multiple debugging tools are found, the debugging tools list menu is\n    displayed. A debug tool can be started by selecting the name option\n    corresponding to it.\n 4. When no debug tool is found, the user is informed that no debug tool is\n    available.\n\nIn addition to the dev command, you can also start a debugging tool or task\ndirectly by using the dev [debug tool name] option.\n\n\nExtending the dev command#\n\nIf you need to extend the dev command, or rather provide your own Module Tools\ndebugging tool plug-in, then you will need to know the following first.\n\n * Development of plugins\n * Debugging Tools Plugin API\n\nIn general, the code to implement a debugging tool that does nothing and the\nassociated configuration is as follows.\n\nexport const myPlugin = (): CliPlugin => ({\n  name: 'do-nothing',\n  setup() {\n    return {\n      registerDev() {\n        return {\n          // Debugging tool name\n          name: 'do-nothing',\n          // Menu display content\n          menuItem: {\n            name: 'DoNothing',\n            value: 'do-nothing',\n          },\n          // The defined dev subcommand\n          subCommands: ['donothing', 'dn'],\n          async action() {\n            // dev logic\n            console.info('Run build --watch, and do nothing.');\n          },\n        };\n      },\n    };\n  },\n});\n\n\nIf this debugging tool plugin is required, it needs to be added to the\nconfiguration file.\n\n\n\nexport default defineConfig({\n  plugins: [\n    //..\n    doNothingPlugin()\n  ],\n});\n\n\nAt this point we can execute it when we execute the dev or dev do-nothing\ncommand. After execution, it will first execute the source build task in\nlistening mode and print the log messages immediately afterwards.\n\nFor currently officially supported debugging tools and third-party supported\ndebugging tools, you can view them in plugins list.","frontmatter":{"sidebar_position":2},"_filepath":"/Users/bytedance/github/targeral/modern-js/packages/document/module-doc/docs/en/guide/advance/in-depth-about-dev-command.md","_relativePath":"en/guide/advance/in-depth-about-dev-command.md"},{"id":14,"title":"Theme Configuration","routePath":"/module-tools/en/guide/advance/theme-config","lang":"en","toc":[{"text":"Motivation and rationale","id":"motivation-and-rationale","depth":2,"charIndex":94},{"text":"Usage examples","id":"usage-examples","depth":2,"charIndex":1115},{"text":"tailwindcss","id":"tailwindcss","depth":3,"charIndex":1133},{"text":"HTML Class","id":"html-class","depth":4,"charIndex":1484},{"text":"@apply Directives","id":"@apply-directives","depth":4,"charIndex":1574}],"domain":"","content":"#\n\nThe module project provides the ability to configure themes through the\ndesignSystem API.\n\n\nMotivation and rationale#\n\nTheme configuration is somewhat similar to the custom theme functionality in the\ncomponent library and is mainly used in style development. We can use the\ndesignToken generated by the designSystem configuration in different style\ndevelopment environments.\n\nThe so-called designToken corresponds to different things in different style\ndevelopment environments.\n\n * tailwindcss: use designSystem as the theme configuration for tailwindcss. So\n   you can use.\n   * The name of the HTML class supported by tailwindcss.\n   * @apply custom directive under css/less/sass to use a string with the same\n     name as the HTML class name supported by tailwindcss.\n * css/less/scss: Generate global style variables via designSystem.\n\nThe data structure of the designSystem API is borrowed from the theme API in the\ntailwindcss configuration object, so a default set of designToken exists. For\nthe default values, see the designSystem API.\n\nINFO\n\nThe css/less/sass global variables are not supported yet.\n\n\nUsage examples#\n\n\ntailwindcss#\n\nWhen using tailwindcss, its theme configuration can be set via designSystem.\n\nFor example, the following configuration extends the original color\nconfiguration:\n\nexport default {\n  designSystem: {\n    extend: {\n      colors: {\n        primary: '#1677ff',\n      },\n    },\n  },\n};\n\n\nWe can have two ways of using tailwindcss in our code.\n\nHTML Class#\n\nimport 'tailwindcss/utilities.css';\n\nexport default () => {\n  return \n;\n};\n\n\n@apply Directives#\n\nINFO\n\nAbout @apply。","frontmatter":{"sidebar_position":7},"_filepath":"/Users/bytedance/github/targeral/modern-js/packages/document/module-doc/docs/en/guide/advance/theme-config.mdx","_relativePath":"en/guide/advance/theme-config.mdx"},{"id":15,"title":"Before you start","routePath":"/module-tools/en/guide/basic/before-getting-started","lang":"en","toc":[{"text":"Environment preparation","id":"environment-preparation","depth":2,"charIndex":3},{"text":"Getting Started with npm","id":"getting-started-with-npm","depth":2,"charIndex":446},{"text":"npm package type project","id":"npm-package-type-project","depth":2,"charIndex":928},{"text":"Using third-party npm packages","id":"using-third-party-npm-packages","depth":2,"charIndex":2148},{"text":"Other npm bits and pieces to know","id":"other-npm-bits-and-pieces-to-know","depth":2,"charIndex":4015},{"text":"Program entry for npm packages","id":"program-entry-for-npm-packages","depth":3,"charIndex":4052},{"text":"\\\"scripts\\\"","id":"\\\"scripts\\\"","depth":3,"charIndex":-1},{"text":"npm install","id":"npm-install","depth":4,"charIndex":5752},{"text":"npm publish","id":"npm-publish","depth":4,"charIndex":6113},{"text":"peerDependencies","id":"peerdependencies","depth":3,"charIndex":6383},{"text":"npm package manager","id":"npm-package-manager","depth":2,"charIndex":7085},{"text":"Module Tools configuration file","id":"module-tools-configuration-file","depth":2,"charIndex":7370}],"domain":"","content":"#\n\n\nEnvironment preparation#\n\nIn order to use the Modern.js module engineering solution, you first need NodeJS\nengine, we recommend the latest LTS version, and make sure the Node version is\n>=14.18.0. because non-stable NodeJS releases frequently have bugs. You might\nconsider installing via nvm-windows and nvm (Mac / Linux), so you can easily\nswitch to different NodeJS versions that might be required for different\nprojects that you work on.\n\n\nGetting Started with npm#\n\nOnce NodeJS is installed, not only can you access the node executable from the\ncommand line, but you can also execute the npm command.\n\nNpm is the standard package manager for NodeJS. It started out as a tool for\ndownloading and managing NodeJS package dependencies, but it has since evolved\ninto a tool for front-end JavaScript.\n\nIf you already know something about usage of npm and npm packages, then you can\ndirectly see npm package manager section.\n\n\nnpm package type project#\n\nSo what is an npm package type project? When we execute the npm init command in\nan empty project directory, it creates a JSON file with the file name\npackage.json under the current directory. During the creation process, we will\nneed to fill in information including but not limited to the name, version\nnumber, description, etc. of the npm package, which will be found in the\nresulting package.json file as follows\n\n{\n  \"name\": \"npm-demo\",\n  \"version\": \"1.0.0\",\n  \"description\": \"\",\n  \"main\": \"index.js\",\n  \"scripts\": {\n    \"test\": \"echo \\\"Error: no test specified\\\" && exit 1\"\n  },\n  \"author\": \"\",\n  \"license\": \"ISC\"\n}\n\n\nAt this point the project containing the initialized package.json file is an npm\npackage type project, and you can execute the npm publish command to publish the\nproject to the npm Registry.\n\nThe npm Registry is a npm package store where developers can not only publish\ntheir own npm packages to the npm Registry, but also use npm packages published\nby other developers through the npm Registry.\n\nA quality npm package will be used by more people because it not only saves a\nlot of code implementation work, but is also less likely to cause problems with\nthe project.\n\n\nUsing third-party npm packages#\n\nWhen adding a third-party npm package to an initial project, we can call this\nprocess \"installing dependencies for the project\" or \"adding dependencies to the\nproject\". Before adding dependencies, we need to know one thing in particular --\nthe types of packages npm depends on.\n\n * \"dependencies\": a type of package that your application will need in a\n   production environment.\n * \"devDependencies\": another type of package that is only needed for local\n   development and testing.\n   \n   > packages can be understood as third-party npm packages.\n\nYou can install the packages you need in a production environment by running npm\ninstall npm-package-name or npm add npm-package-name, or you can manually write\nthe packages you need to install and the corresponding semantic version in\n\"dependencies\" in the package.json file, and run the npm install command to.\n\n{\n  \"name\": \"your-npm-project\",\n  \"dependencies\": {\n    \"npm-package-name\": \"0.1.0\"\n  }\n}\n\n\nSimilarly, you can install only packages needed for local development and\ntesting by running npm install npm-package-name --save-dev or npm add\nnpm-package-name --save-dev, or you can manually write the packages to be\ninstalled and the corresponding semantic version in \"devDependencies\" in the\npackage.json file, and run the npm install command as follows\n\n{\n  \"name\": \"your-npm-project\",\n  \"devDependencies\": {\n    \"npm-package-name\": \"0.1.0\"\n  }\n}\n\n\nWhen installing or using third-party npm packages be sure to determine what they\nare for and whether they should be placed in \"dependencies\" or \"devDependencies\"\nby distinguishing between their types.\n\nTIP\n\nIn general, packages that need to be used in source code are dependencies\ndependencies. Unless you are exporting dependent code locally via packaging, in\nwhich case it can be treated as a devDependencies dependency.\n\n\nOther npm bits and pieces to know#\n\n\nProgram entry for npm packages#\n\nThere is a \"main\" attribute in package.json that corresponds to a module ID or,\nmore intuitively, a NodeJS file path, which is the main entry point for your\napplication.\n\nFor example, if your package is named foo and the user installs it, and then\nexecutes the require(\"foo\") code, then the file corresponding to the \"main\"\nfield of the npm package foo will be exported.\n\nIt is recommended to set the \"main\" field in your npm package. If \"main\" is not\nset, the default entry will be the index.js file in the root of the package.\n\nIn addition to the \"main\" attribute, the \"module\" attribute is usually set. It\nis similar to the \"main\" attribute in that it is mainly used in webpack\nscenarios. webpack reads the npm package entry (file) in most cases in the order\n\"module\" -> \"main \".\n\n> To learn more about how webpack does this, check out this link.\n\n\n\"scripts\"#\n\nThe \"scripts\" attribute of the package.json file supports a number of built-in\nscripts and npm-preset lifecycle events, as well as arbitrary scripts.\n\nThese can be executed by running npm run-script or simply npm run .\n\nName matching pre and post commands will also be run (e.g. premyscript,\nmyscript, postmyscript ).\n\n{\n  \"scripts\": {\n    \"premyscript\": \"\",\n    \"myscript\": \"\",\n    \"postmyscript\": \"\"\n  }\n}\n\n\nWhen npm run myscripts is executed, the script corresponding to premyscripts\nwill be executed before it, and the script corresponding to postmyscripts will\nbe executed after it.\n\nScript commands from dependencies can be run with npm explore -- npm run .\n\nThere are also special lifecycle scripts that occur only under certain\ncircumstances. Here are a few that are usually necessary to know.\n\nnpm install#\n\nWhen you run npm install -g , the following scripts will run.\n\n * preinstall\n * install\n * postinstall\n * prepublish\n * preprepare\n * prepare\n * postprepare\n\nIf your package root has a binding.gyp file and you don't define an install or\npreinstall script, then npm will build with node-gyp rebuild as the default\ninstall command, using node-gyp.\n\nnpm publish#\n\nWhen publishing a project, executing this command will trigger the following\nscript.\n\n * prepublishOnly\n * prepack\n * prepare\n * postpack\n * publish\n * postpublish\n\nWhen running in -dry-run mode, the script corresponding to prepare will not be\nexecuted.\n\n\npeerDependencies#\n\nIn some cases, your npm project has a compatibility relationship with its host\ntool or library (e.g. a webpack plugin project and webpack), and your npm\nproject does not want to use the host as a necessary dependency, which usually\nmeans that your project is probably a plugin for that host tool or library. Your\nnpm project will have certain requirements for the version of the host package,\nas only the APIs required by the npm project will be exposed under a specific\nversion.\n\nFor more explanation of peerDependencies, you can learn about the different ways\nnpm, pnpm, and Yarn handle it at the following links.\n\n * npm's explanation of peerDependencies\n * pnpm vs npm vs Yarn\n\n\nnpm package manager#\n\nIn addition to the standard package manager like npm, the mainstream ones are\npnpm and Yarn, both of which are good alternatives to npm cli.\n\nIt is recommended to use pnpm to manage project dependencies, which can be\ninstalled as follows.\n\nnpm install -g pnpm\n\n\n\nModule Tools configuration file#\n\nThe Module Tools configuration file - modern.config.(j|t)s - is provided in the\nproject directory of the module project created with @modern-js/create. However,\nthe modern.config configuration file is not required to exist.\n\nBy default, the contents of the generated configuration file are as follows.\n\n\n\nexport default defineConfig({\n  plugins: [moduleTools()],\n  buildPreset: 'npm-library',\n});\n\n\nWe recommend using the defineConfig function, but it is not mandatory to use it.\nSo you can also return an object directly in the config file: the\n\n\n\nexport default {\n  plugins: [moduleTools()],\n  buildPreset: 'npm-library',\n};\n","frontmatter":{"sidebar_position":1},"_filepath":"/Users/bytedance/github/targeral/modern-js/packages/document/module-doc/docs/en/guide/basic/before-getting-started.md","_relativePath":"en/guide/basic/before-getting-started.md"},{"id":16,"title":"CLI Commands","routePath":"/module-tools/en/guide/basic/command-preview","lang":"en","toc":[{"text":"modern build","id":"modern-build","depth":2,"charIndex":69},{"text":"modern new","id":"modern-new","depth":2,"charIndex":2093},{"text":"modern dev","id":"modern-dev","depth":2,"charIndex":2872},{"text":"modern test","id":"modern-test","depth":2,"charIndex":3456},{"text":"modern lint","id":"modern-lint","depth":2,"charIndex":3764},{"text":"modern change","id":"modern-change","depth":2,"charIndex":4200},{"text":"modern pre","id":"modern-pre","depth":2,"charIndex":4528},{"text":"modern bump","id":"modern-bump","depth":2,"charIndex":4759},{"text":"modern release","id":"modern-release","depth":2,"charIndex":5278},{"text":"modern gen-release-note","id":"modern-gen-release-note","depth":2,"charIndex":5758},{"text":"modern upgrade","id":"modern-upgrade","depth":2,"charIndex":6254}],"domain":"","content":"#\n\nCLI Commands available for Module Tools projects are as follows:\n\n\nmodern build#\n\nUsage: modern build [options]\n\nBuild module command\n\nOptions:\n  -w, --watch Build code in listening mode\n  --tsconfig [tsconfig] Specify the path to the tsconfig.json file (default:\n                         \". /tsconfig.json\")\n  --platform [platform] Build products for all or specified platforms\n  --no-dts disables DTS type file generation and type checking\n  --no-clear disables automatic clearing of product output directories\n  -h, --help Show information about the current command\n\n\nWhen you want to start a project build, you can execute the modern build\ncommand. When using this command, we can:\n\n * When wanting to start a build in watch mode, use the --watch option.\n * When you want to specify the path to the TypeScript configuration file read\n   by the project build, use -build --tsconfig . /path/config.json option. This\n   option overrides all buildConfig configurations in dts.tsconfigPath.\n * The -no-dts option can be used when the DTS type file generation and type\n   checking behavior of the project needs to be turned off. Note: The generation\n   of type files depends on the results of type checking. If type checking is\n   turned off, then type files will not be generated either.\n * The --no-clear option can be used when the automatic clearing of the product\n   output directory needs to be turned off.\n\nIn addition to the above, module projects also support platform build mode,\nwhich can be used to perform build tasks for other tools. For example, it is\ncurrently officially supported to start a Storybook build task to generate\nStorybook products by executing the modern build --platform or modern build\n--platform storybook commands after installing the @modern-js/plugin-storybook\nplugin.\n\nTIP\n\nWhen executing a Storybook build, if you need to read the build product of the\nproject. Then don't forget to execute the modern build command to ensure the\nexistence of the project's build product before executing the modern build\n--platform command to start the Storybook build.\n\n\nmodern new#\n\nUsage: modern new [options]\n\nExecute the generator in a modular project scenario\n\nOptions:\n  -d, --debug Enable Debug mode, print debug log messages (default: false)\n  -c, --config  Generators run default configuration (JSON string)\n  --dist-tag  Generator uses a special version of npm Tag\n  --registry customize npm Registry during generator runtime\n  -h, --help display help for command\n\n\nThe modern new command is used to start the microgenerator functionality, which\nenables features for the project that are not provided by default.\n\nThe following features can currently be enabled.\n\n * Testing support\n * Storybook debugging\n * Tailwind CSS support\n * Modern.js Runtime API\n\nYou can learn more about these features in the Using the micro generator\nsection.\n\n\nmodern dev#\n\nUsage: modern dev [options]\n\nLocal development commands\n\nOptions:\n  -h, --help display help for command\n\nCommands:\n[dev-tools-subCommand]\n\n\nThe module engineering solution provides the ability to use debugging tools,\nwhich can be started with the modern dev command. Note, however, that no\ndebugging-related plugins are provided by default, so executing modern dev will\nprompt: \"No dev tools found available \".\n\nThe officially supported debugging tool is Storybook, so you can run modern dev\nor modern dev storybook to execute it after you run modern new to enable it.\n\n\nmodern test#\n\nUsage: modern test [options]\n\nOptions:\n  -h, --help display help for command\n\n\nYou need to execute modern new to turn on the test function before you can\nexecute the modern test command. The modern test command will automatically run\nthe src/tests/*.test.(js|ts|jsx|tsx) file as a test case.\n\n\nmodern lint#\n\nUsage: modern lint [options] [. .files]\n\nlint and fix source files\n\nOptions:\n  --no-fix disable auto fix source file\n  -h, --help display help for command\n\n\nRun ESLint to check the syntax of the code. Usually, we only need to check the\npart of the code that was changed in this commit with lint-staged during the\n-git commit phase.\n\n * The -no-fix argument turns off the ability to automatically fix lint error\n   code.\n\n\nmodern change#\n\nUsage: modern change [options]\n\nCreate a changeset\n\nOptions:\n  --empty Create an empty changeset (default: false)\n  --open Open the created changeset in the editor (default: false)\n  -h, --help display help for command\n\n\nThe modern change command is used to generate the required Markdown file for\nchangesets.\n\n\nmodern pre#\n\nUsage: modern pre [options]  [tag]\n\nEntering and exiting pre-publishing mode\n\nOptions:\n  -h, --help display help for command\n\n\nYou can use the modern pre command to pre-release a version before the official\nrelease.\n\n\nmodern bump#\n\nUsage: modern bump [options]\n\nUse changesets to automatically update releases and changelogs\n\nOptions:\n  --canary Create a pre-release for testing (default: false)\n  --preid  Specify an identifier when versioning a pre-release (default: \"next\")\n  --snapshot Create a special version for testing (default: false)\n  -h, --help display help for command\n\n\nModify the version number in package.json according to the Markdown file of the\nchangelog generated by changesets, and generate the CHANGELOG.md file.\n\n\nmodern release#\n\nUsage: modern release [options]\n\nRelease npm packages\n\nOptions:\n  --tag  Release npm packages with a specific tag (default: \"\")\n  --ignore-scripts release ignores the scripts command in package.json, only supported in pnpm monorepo\n                    (default: \"\")\n  -h, --help display help for command\n\n\nThe -modern release command releases the module to the npm Registry.\n\n * The -tag argument specifies the specific dist tags to be used for the\n   release.\n\n\nmodern gen-release-note#\n\nUsage: modern gen-release-note [options]\n\nGenerate Release Note based on current repository changeset information\n\nOptions:\n  --repo  The name of the repository to generate the Pull Request link, e.g.: web-infra-dev/modern.js\n  --custom  Custom Release Note generation function\n  -h, --help display help for command\n\n\nAutomatically generate Release Note based on the changeset information of the\ncurrent repository.\n\nTIP\n\nneeds to be executed before the bump command.\n\n\nmodern upgrade#\n\nUsage: modern upgrade [options]\n\nUpgrade Modern.js to the latest version\n\nOptions:\n  --registry  customize npm registry (default: \"\")\n  -d,--debug Enable Debug mode to print debug log messages (default: false)\n  --cwd  project path (default: \"\")\n  -h, --help display help for command\n\n\nThe modern upgrade command is used to upgrade the project Modern.js related\ndependencies to the latest version.\n\nExecuting the command npx modern upgrade in the project root directory will\nupdate the Modern.js dependencies in package.json of the currently executing\nproject to the latest version by default.","frontmatter":{"sidebar_position":2},"_filepath":"/Users/bytedance/github/targeral/modern-js/packages/document/module-doc/docs/en/guide/basic/command-preview.md","_relativePath":"en/guide/basic/command-preview.md"},{"id":17,"title":"Modify the output product","routePath":"/module-tools/en/guide/basic/modify-output-product","lang":"en","toc":[{"text":"Default output products","id":"default-output-products","depth":2,"charIndex":3},{"text":"buildPreset","id":"buildpreset","depth":2,"charIndex":1066},{"text":"String form of build preset","id":"string-form-of-build-preset","depth":3,"charIndex":1339},{"text":"Build pre-defined function forms","id":"build-pre-defined-function-forms","depth":3,"charIndex":2873},{"text":"Build configuration (object)","id":"build-configuration-(object)","depth":2,"charIndex":4535},{"text":"When to use buildConfig","id":"when-to-use-buildconfig","depth":2,"charIndex":7754}],"domain":"","content":"#\n\n\nDefault output products#\n\nWhen you use the modern build command in an initialized project, Module Tools\nwill generate corresponding build products based on the current configuration.\n\nThe default configuration is as follows:\n\n\n\nexport default defineConfig({\n  // Register the CLI tool of Module Tools\n  plugins: [moduleTools()],\n  // Specify the build preset configuration\n  buildPreset: 'npm-library',\n});\n\n\nThe default generation product has the following characteristics.\n\n * will generate CommonJS and [ESM](https://nodejs.org/api/esm.html#modules-\n   ecmascript-modules).\n * The code syntax is supported up to ES6 , and more advanced syntax will be\n   converted.\n * All code is packaged into one file, i.e. bundle processing is performed.\n * The output root directory is the dist directory under the project, and the\n   type file output directory is dist/types.\n\nYou may have the following questions when you see this.\n\n 1. what is buildPreset?\n 2. what determines these characteristics of the product?\n\nThen the next step is to first explain buildPreset.\n\n\nbuildPreset#\n\nThe buildPreset represents one or more sets of build-related configurations\nprepared in advance. By using the corresponding preset values of the\nbuildPreset, you can eliminate the troublesome and complicated configuration\nwork and get the expected product.\n\n\nString form of build preset#\n\nThe value of a build preset can be in the form of a string, so a build preset of\nthis form is called a preset string.\n\nThe module engineering solution provides generic build preset strings and\ncorresponding variants, depending on the generic scenario in which the npm\npackage is used. All currently supported preset strings can be viewed via the\nBuildPreset API. Here is an explanation about the relationship between generic\npreset strings and variants.\n\nAmong the generic preset strings, \"npm-library\" can be used in the scenario of\ndeveloping npm packages of the library type, which is suitable for most common\nmodule type projects. When \"npm-library\" is set, the output product of the\nproject will have the following characteristics.\n\n * In the dist/lib directory you will get code formatted as cjs, syntax\n   supported up to es6 and packaged.\n * In the dist/es directory, you get code in the format esm, with syntax support\n   up to es6 and after packaging.\n * In the dist/types directory, you get the type files. If it is not a\n   TypeScript project, there is no such directory.\n\nThe default string \"npm-library\" is a variant of the original product with a\nmodified code syntax support feature and a string naming change to\n\"npm-library-[es5 | es2016.... . es2020 | esnext]\".\n\nFor example, if the output product is based on the preset string \"npm-library\"\nand the syntax supported by the product code is changed to es5, then simply\nchanging \"npm-library\" to \"npm-library-es5\" would be sufficient.\n\n\nBuild pre-defined function forms#\n\nIn addition to the string form, the value of a build preset can also be in the\nform of a function, where the specific configuration corresponding to a preset\nvalue can be printed or modified.\n\nFor example, to achieve the same effect as the preset string ``npm-library-es5\"`\nusing the form of a preset function, you can do the following.\n\n\n\nexport default defineConfig({\n  plugins: [moduleTools()],\n  buildPreset({ preset }) {\n    return preset.NPM_LIBRARY.map(config => {\n      return { ... .config, target: 'es5' }\n    });\n  },\n});\n\n\nIn the above code implementation, preset.NPM_LIBRARY corresponds to the preset\nstring \"npm-library\", representing multiple build-related configurations\nequivalent to \"npm-library\".\n\nWe use the map method to iterate over the NPM_LIBRARY array, which contains\nmultiple buildConfig objects. We perform a shallow copy of the original\nbuildConfig object and modify the value of the target property in the shallow\ncopy to be es5.\n\nIf you want to know the specific contents included in preset.NPM_LIBRARY, you\ncan refer to the BuildPreset API.\n\nIn addition, under the preset object, it not only includes NPM_LIBRARY, but also\nother similar constants.\n\n> NPM_LIBRARY, you can check it with [BuildPreset\n> API](/api/config/build-preset). Thepresetobject contains not onlyNPM_LIBRARY`,\n> but also other similar constants.\n\nTIP\n\nWe can not only use preset.NPM_LIBRARYto get the build configuration\ncorresponding to\"npm-library\", but also preset['npm-library'] in this way.\n\nSo what is the buildConfig object here? What is the basis for the build product\nfeature mentioned before?\n\nLet's explain next.\n\n\nBuild configuration (object)#\n\nbuildConfig is a configuration option that describes how to compile and generate\nbuild products. What was mentioned at the beginning about \"features of build\nproducts\" are actually properties supported by buildConfig. The currently\nsupported properties cover the needs of most module type projects when building\nproducts. buildConfig not only contains some properties that products have, but\nalso contains some features needed to build products. The following is a brief\nlist from a classification point of view.\n\nThe basic attributes of a build product include:\n\n * Whether the product is packaged or not: the corresponding API is\n   buildConfig.buildType.\n * Product support for syntax: the corresponding API is buildConfig.target.\n * Output format: the corresponding API is buildConfig.format.\n * How the output type file is handled: the corresponding API is\n   buildConfig.dts.\n * How the sourceMap of the product is handled: the corresponding API is\n   buildConfig.sourceMap.\n * The input (or source file) corresponding to the output: the corresponding API\n   is buildConfig.input.\n * The directory of the output of the product: the corresponding API is\n   buildConfig.outDir.\n * Build source directory: the corresponding API is buildConfig.sourceDir.\n\nCommon functions required for build products include:\n\n * Alias: The corresponding API is buildConfig.alias.\n * Static resource handling: the corresponding API is buildConfig.asset.\n * Third-party dependency handling: The corresponding APIs are\n   * buildConfig.autoExternal.\n   * buildConfig.externals.\n * Copy: The corresponding API is buildConfig.copy.\n * Global variable substitution: the corresponding API is buildConfig.define.\n * Specify JSX compilation method, the corresponding API is\n   [buildConfig.jsx](/api/config/ build-config#jsx).\n\nSome advanced properties or less frequently used functions:\n\n * Product code compression: The corresponding API is buildConfig.minify.\n * Code splitting: buildConfig.splitting\n * Specify whether the build product is for the NodeJS environment or the\n   browser environment: the corresponding API is buildConfig.platform.\n * umd product-related.\n   * Specifies the global variables imported externally to the umd product: the\n     corresponding API is buildConfig.umdGlobals.\n   * Specify the module name of the umd product: the corresponding API is\n     buildConfig.umdModuleName.\n\nIn addition to the above categories, frequently asked questions and best\npractices about these APIs can be found at the following links\n\n * [What are bundle and bundleless?](/guide/advance/in-depth-about-build#bundle-\n   and-bundleless)\n * [Relationship of input to\n   sourceDir](/guide/advance/in-depth-about-build#input- to -sourcedir-)\n * Multiple ways to generate type files in product.\n * [buildConfig.define Different ways to use it for different\n   scenarios.](/guide/advance/in-depth-about-build#buildconfigdefine - How to\n   use it for different scenarios)\n * How to handle third-party dependencies?\n * How to use copy?\n * How do I build umd products? (/guide/advance/build-umd# sets the global\n   variable name of the project)\n * The capabilities currently supported by static resources.\n\n\nWhen to use buildConfig#\n\nbuildConfig is one of the methods used to modify the product, only buildConfig\nwill take effect when configured in conjunction with buildPreset. So if\nconfigured as follows.\n\n\n\nexport default defineConfig({\n  buildConfig: {\n    format: 'umd',\n  },\n  buildPreset: 'npm-library',\n});\n\n\nThen at this point you will see the following prompt.\n\nSince both 'buildConfig' and 'buildPreset' are present, only the 'buildConfig' configuration will take effect\n\n\nThe set or sets of build-related configurations represented by buildPreset are\ncomposed of buildConfig, which can be used to customize output products when the\ncurrent project needs cannot be met using buildPreset.\n\nThe process of using buildConfig is the process of thinking about what kind of\nbuild product to get.","frontmatter":{"sidebar_position":3},"_filepath":"/Users/bytedance/github/targeral/modern-js/packages/document/module-doc/docs/en/guide/basic/modify-output-product.md","_relativePath":"en/guide/basic/modify-output-product.md"},{"id":18,"title":"Versioning and Publishing","routePath":"/module-tools/en/guide/basic/publish-your-project","lang":"en","toc":[{"text":"Tracking changes","id":"tracking-changes","depth":2,"charIndex":402},{"text":"Version update","id":"version-update","depth":2,"charIndex":1744},{"text":"Publish","id":"publish","depth":2,"charIndex":2223},{"text":"Pre-releases","id":"pre-releases","depth":2,"charIndex":2937}],"domain":"","content":"#\n\nAn npm-type module project release process consists of two phases.\n\n * The first phase is during development, where the developer needs to provide a\n   change file to record changes that need to be released.\n * The second phase is during release, where Module Tools can collect all the\n   change files to update the version, update the release log, and release new\n   packages to the npm Registry.\n\n\nTracking changes#\n\nChanges need to be logged when they happen to the project. Changes that occur in\na project are typically.\n\n * New features\n * Fixes to issues\n * Configuration file changes\n * ...\n\nOnce these changes have been made, the current changes need to be documented\nwith the following command.\n\n * modern change\n\nExecuting the modern change command asks the developer several questions and\ngenerates a change log based on the developer's answers. The changelog file\ncontains the type of change and its description, and is committed to the git\nrepository.\n\n$ npx modern change\n🦋 What kind of change is this for module-example? (current version is 0.1.0) - patch\n🦋 Please enter a summary for this change (this will be in the changelogs). Submit empty line to open external editor\n🦋 Summary - publish test\n🦋 === Releasing the following packages ===\n🦋 [Patch]\n🦋 module\n🦋 Is this your desired changeset? (Y/n) - true\n🦋 Changeset added! - you can now commit it\n🦋\n🦋 If you want to modify or expand on the changeset summary, you can find it here\n🦋 info /xxxxxx/module/.changeset/brave-dryers-agree.md\n\n\nWhen executed successfully, the resulting Markdown file containing the change\nlog is saved in the project's .changeset directory. The contents will look like\nthe following.\n\n---\n\"``module-example'': patch\n---\n\npublish test\n\n\n\nVersion update#\n\nWhen the project version needs to be updated, execute the following command.\n\n * modern bump\n\nExecuting modern bump will modify the version number in package.json based on\nthe contents of the Markdown file in the .changeset/ directory where the changes\nwere recorded, and generate the CHANGELOG.md file. These Markdown files are also\ndeleted when the version update is complete, so they are \"consumed \".\n\n# module\n\n## 0.1.1\n\n### Patch Changes\n\n- publish test\n\n\n\nPublish#\n\nTo publish a project, you can execute the following command.\n\n * modern publish\n\nThe modern release command publishes the project to the npm Registry.\n\nThe release is the latest version, which is also the official version. If you\nwant to change the dist-tag, you can specify it with the modern release --tag\ncommand. For example.\n\nmodern release --tag beta\n\n\nHowever, if you want to change the version number of the current project to a\npre-release as well, you need to use the modern pre command.\n\n> dist-tag can be understood as: tagging the current release. Generally\n> speaking, the dist-tag for the default release is latest, so you can consider\n> latest as the dist-tag for the official release.\n\n\nPre-releases#\n\nWhen a pre-release is needed before the official release, the following command\nis executed.\n\n * modern pre\n\nFirst modern pre enter to enter pre-release mode, can be the same as the tag\nspecified with the modern release --tag command when releasing the project.\n\n$ npx modern pre enter next\n🦋 success Entered pre mode with tag next\n🦋 info Run `changeset version` to version packages with prerelease versions\n✨ Done in 5.30s.\nDone in 5.30s. ```\n\nThen you can update the specific version number with the `modern bump` command, **which doesn't actually \"consume\" the Markdown file that records the changes**: ``` bash\n\n``` bash\n$ npx modern bump\n🦋 warn ===============================IMPORTANT!===============================\n🦋 warn You are in prerelease mode\n🦋 warn If you meant to do a normal release you should revert these changes and run `changeset pre exit`\n🦋 warn You can then run `changeset version` again to do a normal release\n🦋 warn ----------------------------------------------------------------------\n🦋 All files have been updated. review them and commit at your leisure\n\n\nThen you can see that the updated version number in package.json will look like\nthis: 0.1.2-next.0.\n\nFinally, if you don't need to do a pre-release anymore, be sure to run the\nmodern pre exit command to exit the pre-release state and to release the\nofficial version when you run the modern bump command again.","frontmatter":{"sidebar_position":7},"_filepath":"/Users/bytedance/github/targeral/modern-js/packages/document/module-doc/docs/en/guide/basic/publish-your-project.md","_relativePath":"en/guide/basic/publish-your-project.md"},{"id":19,"title":"Testing Projects","routePath":"/module-tools/en/guide/basic/test-your-project","lang":"en","toc":[{"text":"Prerequisites and conventions","id":"prerequisites-and-conventions","depth":2,"charIndex":52},{"text":"Run the tests","id":"run-the-tests","depth":2,"charIndex":758},{"text":"Usage Configuration","id":"usage-configuration","depth":2,"charIndex":1028},{"text":"Test example","id":"test-example","depth":2,"charIndex":1187},{"text":"Common modules","id":"common-modules","depth":3,"charIndex":1203},{"text":"Components","id":"components","depth":3,"charIndex":1283}],"domain":"","content":"#\n\nThis chapter will describe how to test modules.\n\n\nPrerequisites and conventions#\n\nTo use the testing features of the project, you need to make sure that the\nproject contains the dependency: \"@modern-js/plugin-testing\" , which can be done\nwith modern new.\n\nIn the module engineering scheme, the following conventions are in place for\ntest cases, or files for writing tests:\n\n * The tests directory in the project directory is the directory for test cases\n   and test files, no support for changing the directory for running test cases.\n * Files with the suffix .test.[tj]sx? are automatically recognized as test\n   files by default.\n * Other . [tj]sx? suffixes are recognized as normal files that can be used as\n   test utils files or for other purposes.\n\n\nRun the tests#\n\nOnce the dependencies are prepared and we know where to write the test cases, we\ncan execute the tests with the following command:\n\nmodern test\n\n// Update snapshot\nmodern test --updateSnapshot\n\n\nAfter execution, you will see the results of the test:\n\n\n\n\nUsage Configuration#\n\nThe Module Engineering Program provides the following configurations for\ntesting.\n\n * testing\n\nYou can add it in modern.config.(j|t)s.\n\n\nTest example#\n\n\nCommon modules#\n\nFor common modules, we can use the test function as follows:\n\n\nComponents#\n\nFor components, Modern.js's Runtime API provides functionality for testing UI\ncomponents, which is provided by @modern-js/runtime/testing.\n\nTIP\n\nIf you need to use the Runtime API, then you can turn it on via microgenerator.","frontmatter":{"sidebar_position":6},"_filepath":"/Users/bytedance/github/targeral/modern-js/packages/document/module-doc/docs/en/guide/basic/test-your-project.mdx","_relativePath":"en/guide/basic/test-your-project.mdx"},{"id":20,"title":"Using the Microgenerator","routePath":"/module-tools/en/guide/basic/use-micro-generator","lang":"en","toc":[{"text":"Test","id":"test","depth":2,"charIndex":456},{"text":"Storybook","id":"storybook","depth":2,"charIndex":946},{"text":"Tailwind CSS support","id":"tailwind-css-support","depth":2,"charIndex":1595},{"text":"Modern.js Runtime API","id":"modernjs-runtime-api","depth":2,"charIndex":2100}],"domain":"","content":"#\n\nThe Module Engineering solution provides the Microgenerator tool, which allows\nfor the current project to.\n\n * add new directories and files\n * Modify the contents of the package.json file\n * Execute commands\n\nThus with these capabilities, Microgenerator can enable additional feature\nfunctionality for the project.\n\nThe microgenerator can be started via modern new. The current Microgenerator\nfeatures supported by the Module Engineering program are:\n\n\nTest#\n\nWhen we want to test some modules, we can enable the test feature. When this\nfeature is enabled, a tests directory and related files will be created in the\nproject directory, and a new \"@modern-js/plugin-testing\" dependency will be\nadded to package.json.\n\nTIP\n\nAfter successfully enabling it, you will be prompted to manually add a code\nsimilar to the one below to the configuration.\n\n\n\n\nexport default defineConfig({\n  plugins: [\n    moduleTools(),\n    testingPlugin(),\n  ],\n});\n\n\n\nStorybook#\n\nThe Storybook feature can be enabled when we want to debug a component or a\ncommon module. When this feature is enabled, the stories directory and related\nfiles are created in the project directory, and a new\n\"@modern-js/plugin-storybook\" dependency is added to package.json.\n\nTIP\n\nAfter successfully enabling it, you will be prompted to manually add a code\nsimilar to the one below to the configuration.\n\n\n\n\nexport default defineConfig({\n  plugins: [\n    moduleTools(),\n    storybookPlugin(),\n  ],\n});\n\n\nFor more information on how to start Storybook and how to use it, check out the\nfollowing link.\n\n * modern dev\n * using Storybook\n\n\nTailwind CSS support#\n\nThis can be enabled when we want to add Tailwind CSS support to our project.\nTailwind CSS is a CSS library that provides out-of-the-box styling.\n\nFor more information on how to use Tailwind CSS in your module projects, check\nout.\n\n * Using Tailwind CSS\n\nTIP\n\nAfter successfully enabling it, you will be prompted to manually add a code\nsimilar to the one below to the configuration.\n\n\n\n\nexport default defineConfig({\n  plugins: [\n    moduleTools(),\n    tailwindPlugin(),\n  ],\n});\n\n\n\nModern.js Runtime API#\n\nModern.js provides Runtime API capabilities that can only be used in the\nModern.js application project environment. If you need to develop a component\nfor use in a Modern.js application environment, then you can turn on this\nfeature and the microgenerator will add the \"@modern-js/runtime\" dependency.\n\nAlso, the Storybook debugging tool will determine if the project needs to use\nthe Runtime API by checking the project's dependencies and providing the same\nRuntime API runtime environment as the Modern.js application project.\n\nTIP\n\nAfter successfully enabling it, you will be prompted to manually add a code\nsimilar to the one below to the configuration.\n\n\n\n\nexport default defineConfig({\n  plugins: [\n    moduleTools(),\n    runtime(),\n  ],\n});\n","frontmatter":{"sidebar_position":4},"_filepath":"/Users/bytedance/github/targeral/modern-js/packages/document/module-doc/docs/en/guide/basic/use-micro-generator.md","_relativePath":"en/guide/basic/use-micro-generator.md"},{"id":21,"title":"Using Storybook","routePath":"/module-tools/en/guide/basic/using-storybook","lang":"en","toc":[{"text":"Debugging code","id":"debugging-code","depth":2,"charIndex":678},{"text":"Referencing component products","id":"referencing-component-products","depth":3,"charIndex":1318},{"text":"Referencing component source code","id":"referencing-component-source-code","depth":3,"charIndex":2411},{"text":"Configure Storybook","id":"configure-storybook","depth":2,"charIndex":3252},{"text":"Building Storybook Products","id":"building-storybook-products","depth":2,"charIndex":4191}],"domain":"","content":"#\n\nFirst of all, if you haven't read the following, take a few minutes to\nunderstand it first.\n\n * use micro-generator to enable Storybook debugging\n * modern dev\n\nStorybook is a tool dedicated to component debugging, providing around component\ndevelopment.\n\n * Develop UIs that are more durable\n * Test UIs with less effort and no flakes\n * Document UI for your team to reuse\n * Share how the UI actually works\n * Automate UI workflows\n\nSo Storybook is a complex and powerful tool.\n\nModule Tools is integrated with Storybook, so you can pretty much follow the\nofficial Storybook documentation. However, there are still a few things to keep\nin mind, which are explained below.\n\n\nDebugging code#\n\nThe project code needs to be introduced during the debugging process and can\ncurrently be introduced in two ways:\n\n * Use of project products\n * Using the project source code\n\nWe recommend using the first \"referenced project product\" approach. Because it\nis closer to the real usage scenario, not only can we debug the component\nfunctionality, but also verify the correctness of the build product. However, we\ncan also refer to the source code when testing the project functionality and\nrefer to the project package name when verifying the project product.\n\nNext, we will talk about how to use each of these two methods.\n\n\nReferencing component products#\n\nIf the TypeScript project foo exists.\n\nIf, during development, you encounter a situation where the type definition is\nnot available in real time, at that point.\n\nFor pnpm projects, package.json can be modified as follows.\n\n{\n    \"name\": \"foo\",\n    \"main\": \"./dist/index.js\",\n    \"types\": \"./src/index.ts\",\n    \"publishConfig\": {\n      \"types\": \"./dist/index.d.ts\",\n    }\n}\n\n\n> For the use of pnpm's publishConfig, you can read the following link.\n\nFor npm and Yarn projects, the values of types of package.json can only be\nchanged manually in development phase and release phase.\n\nSo why is it possible to reference the product directly?\n\n 1. execute modern build --watch command before executing modern dev storybook\n    command to ensure the existence of project build products.\n 2. Add processing logic inside Storybook to ensure that the project's product\n    paths can be parsed according to package.json, based on the\n    compilerOptions.paths configuration in the tsconfig.json file or (in JS\n    projects) directly with the project name as an alias.\n\n\nReferencing component source code#\n\nReferencing component source code can be done by means of relative paths to:\n\n\n\nconst Component = () => \nthis is a Story Component {content};\n\nexport const YourStory = () => ;\n\nexport default {\n  title: 'Your Stories',\n};\n\n\nWhy is the source code approach not recommended\n\nNot only is it impossible to verify that the component product is correct using\nthe component source code, but also some of the configurations supported by the\nmodule project for building the product cannot be fully translated into\nStorybook internal configuration. If some of the configurations cannot be\nconverted to each other, there will be unintended results during Storybook\ndebugging.\n\nModule Tools is based on esbuild, while Storybook is based on Webpack, and\nesbuild's configuration is not fully compatible with Webpack.\n\n\nConfigure Storybook#\n\nStorybook is officially configured for projects through a folder called\n.storybook, which contains various configuration files. In a module project\nscenario, Storybook configuration files can be added to the config/storybook\ndirectory of the project.\n\nFor more information on how to use the various Storybook configuration files,\nsee the following links:\n\n * Configure Storybook\n\nBut there are some limitations to Storybooking in a module project:\n\n * It is currently not possible to change the location of the Story file, i.e.,\n   you cannot change the stories configuration in the main.js file.\n * Currently you cannot modify Webpack and Babel related configuration, i.e. you\n   cannot modify webpackFinal and babel configuration in the main.js file.\n\nIn the future we will consider whether these configurations can be allowed to be\nmodified, but for now we are limiting their use to reduce unpredictable issues.\n\n\nBuilding Storybook Products#\n\nIn addition to Storybook debugging of components or common modules, you can also\nperform Storybook build tasks with the following commands.\n\nmodern build --platform storybook\n\n\nFor the modern build --platform command you can see.\n\n * modern build\n\nAfter the build is complete, you can see the build product files in the\ndist/storybook-static directory.","frontmatter":{"sidebar_position":5},"_filepath":"/Users/bytedance/github/targeral/modern-js/packages/document/module-doc/docs/en/guide/basic/using-storybook.mdx","_relativePath":"en/guide/basic/using-storybook.mdx"},{"id":22,"title":"Developing Components","routePath":"/module-tools/en/guide/best-practices/components","lang":"en","toc":[{"text":"Initialize the project","id":"initialize-the-project","depth":2,"charIndex":104},{"text":"Debugging code with Storybook","id":"debugging-code-with-storybook","depth":2,"charIndex":130},{"text":"Developing Styles","id":"developing-styles","depth":2,"charIndex":163},{"text":"CSS/PostCSS","id":"css/postcss","depth":3,"charIndex":369},{"text":"Less","id":"less","depth":3,"charIndex":719},{"text":"Sass/Scss","id":"sass/scss","depth":3,"charIndex":830},{"text":"Tailwind CSS","id":"tailwind-css","depth":3,"charIndex":951},{"text":"HTML class","id":"html-class","depth":4,"charIndex":1190},{"text":"@apply","id":"@apply","depth":4,"charIndex":1203},{"text":"Recommended method","id":"recommended-method","depth":4,"charIndex":1733},{"text":"The difference between bundle and bundleless build products","id":"the-difference-between-bundle-and-bundleless-build-products","depth":4,"charIndex":2127},{"text":"CSS Modules","id":"css-modules","depth":3,"charIndex":3142},{"text":"Configuring build products","id":"configuring-build-products","depth":2,"charIndex":3500},{"text":"Testing components","id":"testing-components","depth":2,"charIndex":4431},{"text":"Releasing components","id":"releasing-components","depth":2,"charIndex":4534}],"domain":"","content":"#\n\nThis chapter will describe how to develop component projects using the module\nengineering solution.\n\n\nInitialize the project#\n\n\nDebugging code with Storybook#\n\n\nDeveloping Styles#\n\nNext we can add styles to the component.\n\nThe following capabilities are currently supported for developing styles.\n\n * CSS/PostCSS\n * Less\n * Scss/Sass\n * Tailwind CSS\n * CSS Modules\n\n\nCSS/PostCSS#\n\nThe module project supports PostCSS and has the following built-in PostCSS\nplugins.\n\n * flexbugs-fixes\n * custom-properties\n * initial\n * page-break\n * font-variant\n * media-minmax\n * nesting\n\nSo we can create .css files in our projects and use the syntax support and\ncapabilities provided by these plugins directly in our css files.\n\n\nLess#\n\nModule projects support development styles using Less.\n\n> The current built-in Less version is v4.1.3\n\n\nSass/Scss#\n\nModule projects support developing styles using Scss/Sass.\n\n> The current built-in Sass version is v1.54.4\n\n\nTailwind CSS#\n\nThe module project supports the development of component styles using Tailwind\nCSS.\n\nBy default, this feature is not enabled in the module project, you need to\nenable it as follows.\n\nTailwind CSS offers two ways to use it.\n\nHTML class#\n\n@apply#\n\nTailwind CSS provides the @apply directive, which allows us to inline the styles\nprovided by Tailwind CSS into the styles we write.\n\n@apply can be used in CSS, Less, and Sass.\n\n.btn {\n  @apply font-bold py-2 px-4 rounded;\n}\n\n\nHowever, there are some things to keep in mind when using Less and Sass.\n\nSass#\n\nWhen using Tailwind with Sass, the presence of !important after @apply requires\ninterpolation to get Sass to compile correctly.\n\nLess#\n\nWhen using Tailwind with Less, you cannot nest Tailwind's @screen directive.\n\nRecommended method#\n\n**It is recommended to develop styles in the way specified by @apply, so that\nonly styles inlined by directives are included in the style product. **\n\nWhen adding styles using HTML class names, by default Tailwind will not only add\nthe styles corresponding to its own class name to the product, but will also\nhave additional style code that may not affect its own styles.\n\nThe difference between bundle and bundleless build products#\n\nFor the following code, there is a big difference between the bundle and\nbundleless modes of building products.\n\n> The so-called bundle and bundleless can be found in [\"Bundle and\n> Bundleless\"](/en/guide/advance/in-depth-about-build#bundle- and-bundleless)\n\nimport 'tailwindcss/utilities.css';\n\nexport default () => {\n  return \nhello world11;\n};\n\n\nIn Bundle mode, third-party dependencies are packaged in.\n\nFor styles, a separate product file is generated, and there is no code related\nto importing styles in the JS output files.\n\nIf you need to inject styles into JS products, you can enable the style.inject\noption.\n\nIn Bundleless mode, no third-party dependencies are packaged in, and no style\nproducts are generated at this time.\n\n\nimport 'tailwindcss/utilities.css';\nvar src_default = () => {\n  return /* @__PURE__ */ jsx('div', {\n    className: 'bg-black text-white',\n    children: 'hello world11',\n  });\n};\nexport { src_default as default };\n\n\n\nCSS Modules#\n\nModule projects support the development of styles using CSS Modules. By default,\nthe following files are recognized as CSS Module files.\n\n * .module.css\n * .module.less\n * .module.scss\n * .module.sass\n\nIf you need to configure CSS Modules, you can check out the API at\n\n * style.autoModules\n * style.modules\n\nThe following is a code example.\n\n\nConfiguring build products#\n\nBased on most scenarios of component project usage, it is recommended to use the\nnpm-component build preset. This preset yields a product directory structure of\n\n.\n├── dist\n│   ├── es\n│   ├── lib\n│   └── types\n\n\n * . /dist/es: Contains bundleless products in ES modules format that support\n   the es6 syntax.\n * . /dist/lib: Contains bundleless products in CommonJS format with support for\n   es6 syntax.\n * . /dist/types: Contains the types file.\n\nThe buildPreset can be configured manually if there is a requirement to use\nsyntax support, and supports modifying the supported syntax by adding a suffix\nto npm-component.\n\nexport default defineConfig({\n  buildPreset: 'npm-component-es2019',\n});\n\n\nIf you have special needs for the build product directory structure, you can use\nthe buildConfig API, which can be used by the following documentation.\n\n * modify-output-product\n * in-depth-about-build\n\n\nTesting components#\n\nFor more information on how to test components, please refer to \"Test project\".\n\n\nReleasing components#\n\nIt is recommended to use module project to provide version publishing function,\nyou can refer to \"Versioning and publishing\".","frontmatter":{},"_filepath":"/Users/bytedance/github/targeral/modern-js/packages/document/module-doc/docs/en/guide/best-practices/components.mdx","_relativePath":"en/guide/best-practices/components.mdx"},{"id":23,"title":"Quick Start","routePath":"/module-tools/en/guide/intro/getting-started","lang":"en","toc":[{"text":"3 minute demo","id":"3-minute-demo","depth":2,"charIndex":3},{"text":"Create new project","id":"create-new-project","depth":3,"charIndex":206},{"text":"Add to an existing project","id":"add-to-an-existing-project","depth":3,"charIndex":1091},{"text":"View official example","id":"view-official-example","depth":3,"charIndex":1977},{"text":"Let\\'s get started","id":"let\\'s-get-started","depth":2,"charIndex":-1}],"domain":"","content":"#\n\n\n3 minute demo#\n\nWant to experience Module Tools in action? The only prerequisite you need is\nNode.js LTS and make sure your Node version is >= 14.18.0.We recommend using the\nLTS version of Node.js 16.\n\n\nCreate new project#\n\nIf you want to create a complete module project, you can execute the following\ncommand:\n\nnpx @modern-js/create your-project-dir-name\n\n\nINFO\n\nExecute npx @modern-js/create -h for more command line arguments\n\nNext, in the issue interaction, follow the options below.\n\n? Please select the type of project you want to create: Npm Module\n? Please fill in the project name: library\n? Please select the programming language: TS\n? Please select the package manager: pnpm\n\n\n> The project name is the value of the \"name\" field in package.json.\n\nThen the process of initializing the project will start. After the project\ndirectory and files are generated and the dependencies are installed, a complete\nmodule project is created.\n\nWe can start the project build directly with the pnpm build command, and start\nthe build in watching mode with the pnpm build --watch command.\n\n\nAdd to an existing project#\n\nFrom your shell, install the following dependencies in your project.\n\n * @modern-js/module-tools\n * \"typescript\" (omitted if not a TypeScript project)\n\n> If it's a TypeScript project, add the \"typescript\" dependency.\n\nnpm install -D @modern-js/module-tools typescript\n\n\n> For projects that use pnpm or the Yarn package manager, just replace npm. pnpm\n> is recommended.\n\nNext, create the modern.config.(t|j)s file in the root of the project.\n\n\n\nexport default defineConfig({\n    plugins: [moduleTools()],\n})\n\n\nFinally, add the command \"build\": \"modern build\" to the project's package.json\nfile.\n\n{\n  \"scripts\": {\n    \"build\": \"modern build\"\n  }\n}\n\n\nIf your project has a src/index.(js|jsx) file or both src/index.(ts|tsx) and\ntsconfig.json files, then congratulations you can run the npm run build command\ndirectly to build your project with Module Tools.\n\n\nView official example#\n\nIf you want to see the complete project using the modular engineering scheme,\nyou can execute the following command.\n\ngit clone https://github.com/web-infra-dev/module-tools-examples\ncd module-tools-example/base\n\n## Execute the build.\npnpm build\n\n## Execute the build in listening mode.\npnpm build --watch\n\n## Start Storybook\npnpm dev storybook\n\n## Test\npnpm test\n\n\n\nLet's get started#\n\nChoose your tutorial scenario...\n\n * I'm a beginner and need to learn basic usage of Module Tools.\n * I have learned the basic usage of Module Tools and can learn advanced usage\n   of Module Tools.\n * I need to expand my project capabilities and need to learn how to develop\n   plugins for Module Tools.","frontmatter":{"sidebar_position":3},"_filepath":"/Users/bytedance/github/targeral/modern-js/packages/document/module-doc/docs/en/guide/intro/getting-started.md","_relativePath":"en/guide/intro/getting-started.md"},{"id":24,"title":"Welcome to Module Tools","routePath":"/module-tools/en/guide/intro/welcome","lang":"en","toc":[],"domain":"","content":"#\n\nModule Tools is a modules engineering solution for Modern.js, as well as a core\ndependency. It allows developers to build, debug, and publish module type\nproject more easily. A module type project can mostly be thought of as an npm\npackage type project, which may be a component, component library or tool\nlibrary project.\n\nIf you are planning to develop a project of the npm package type, then you came\nto the right place! Modern.js provides a professional module engineering\nsolution. It gives you:\n\n * Simple project initialization: simply execute the npx @modern-js/create\n   project-dir command, followed by a few interactive questions, to create a\n   complete module type project. The created project also supports the choice of\n   two package managers, pnpm and Yarn.\n * Code formatting: In a module project, you can execute modern lint to format\n   the code. The initialized module project includes the ESLint ruleset for\n   Modern.js for most scenarios.\n * Comprehensive build capabilities and faster builds: Module Tools provides\n   high-performance build capabilities based on esbuild and SWC, and provides\n   rich configurations for different build scenarios.\n * Storybook debugging tools: Module Tools provides Storybook debugging tools\n   for debugging module projects. After installing the Storybook plugin for\n   Module Tools, you can start it with the modern dev storybook command. You can\n   use Storybook not only for debugging components, but also for other types of\n   modules.\n * Testing capabilities with Jest: When you need to test a module, you can use\n   the modern test command of Module Tools, which not only integrates with Jest,\n   but also provides an API for configuring Jest.\n * Versioning based on Changesets: When you need to record changes to a project,\n   you can use the modern change command to generate a Markdown file containing\n   the changes; when you need to upgrade a project, you can use the modern bump\n   command to analyze and upgrade the version through the Markdown file; when\n   you need to release a project, you can use the modern release command to\n   release the project; Module Tools implements these commands based on\n   Changesets.\n * Extensible plug-in mechanism: Want to integrate additional debugging tools\n   for your project? Or maybe you want to do some extra processing during the\n   build process, Module Tools provides a plugin mechanism and plugin hooks that\n   cover both the dev command and the build command process. You can use them to\n   extend the capabilities of your project.\n * Lots more! Module Tools will continue to optimize its build and debug\n   features in the future. If there are important issues to be solved in module\n   project building, or if a mainstream module project debugging tool or pattern\n   emerges, then they will probably be supported by Module Tools.","frontmatter":{"sidebar_position":1},"_filepath":"/Users/bytedance/github/targeral/modern-js/packages/document/module-doc/docs/en/guide/intro/welcome.md","_relativePath":"en/guide/intro/welcome.md"},{"id":25,"title":"Why module project solution","routePath":"/module-tools/en/guide/intro/why-module-engineering-solution","lang":"en","toc":[],"domain":"","content":"#\n\nYou've probably all experienced it: when developing a component library or tool\nlibrary from scratch, we have to consider not only how to write the code logic\nof the project itself, but also how to build, debug, test, format the code, and\nother things that have nothing to do with the code logic.\n\nFor example, when we consider which builder is used to build the code for a\nmodule project, we might previously consider webpack or Rollup, but now we might\nalso consider esbuild or SWC.\n\nRegardless of which builder is chosen, this is going to be a costly learning\ncurve for developers who are not skilled in the use of these build tools. Even\nif you want to use them quickly, it will take a lot of time and effort.\n\nIn addition to the build, things like providing debugging tools for projects,\nsupporting testing capabilities, adding code format validation, etc. can take a\nlong time and effort for a novice to understand or master them and actually\nserve the current project.\n\nTo ensure the quality of the code and the integrity of the project, we often\nneed to do these things that are not related to the logical implementation of\nthe code. However, these things are likely to affect the overall project\ndevelopment progress, reduce the developer's development experience, and make\nthe developer feel that the development threshold of the module project is very\nhigh.\n\nIf you have to go through all this work every time you develop a module type\nproject, you will spend most of your development time in the beginning on these\nthings that are not related to code implementation. If we could provide a module\nengineering solution that would help developers to solve the project engineering\nissues and allow them to focus more on code implementation, it would greatly\nimprove the module type project development experience.\n\n\n\nModern.js, in order to make developing module type projects easier, provides a\nmodule engineering solution in order to solve the above mentioned problems and\nprovides the main features using Module Tools. Module-tools can be understood as\na tool dedicated to the development of module type projects.","frontmatter":{"sidebar_position":2},"_filepath":"/Users/bytedance/github/targeral/modern-js/packages/document/module-doc/docs/en/guide/intro/why-module-engineering-solution.md","_relativePath":"en/guide/intro/why-module-engineering-solution.md"},{"id":27,"title":"Quick Start","routePath":"/module-tools/en/plugins/guide/getting-started","lang":"en","toc":[],"domain":"","content":"#\n\nModule engineering solution not only provides a rich set of features, but also\nsupports extending the capabilities of the current project by way of plugins.\n\nWe can quickly see how to write a Module Tools plugin by using the following\nexample.\n\nWith the above example, we learned the following things.\n\n * The recommended plugin directory structure\n * The initialization code of the plugin\n * Plugin registration\n\nIn addition to the above, we also need to understand.\n\n * plugin objects, type definitions and recommended configuration items\n * setup functions, api object parameters, lifecycle hooks","frontmatter":{"sidebar_position":1},"_filepath":"/Users/bytedance/github/targeral/modern-js/packages/document/module-doc/docs/en/plugins/guide/getting-started.mdx","_relativePath":"en/plugins/guide/getting-started.mdx"},{"id":28,"title":"Plugin Object","routePath":"/module-tools/en/plugins/guide/plugin-object","lang":"en","toc":[{"text":"Plugin type definitions","id":"plugin-type-definitions","depth":2,"charIndex":558},{"text":"Plugin configuration items","id":"plugin-configuration-items","depth":2,"charIndex":916}],"domain":"","content":"#\n\nThe Module Tools plugin is an object, and the object contains the following\nproperties.\n\n * name: The name of the plugin, a unique identifier.\n * setup: plugin initialization function, which will be executed only once.\n   setup function can return a Hooks object, and Module Tools will execute the\n   function corresponding to the Hook defined on the Hooks object at a specific\n   time.\n\nFor example, in the following plugin code example, the beforeBuild function is\ntriggered before the project starts the build task and the build start log is\nprinted.\n\n\nPlugin type definitions#\n\nWhen using TypeScript, you can introduce the built-in CliPlugin and ModuleTools\ntypes to provide the correct type derivation for plugins: ``\n\n\n\nconst myPlugin: CliPlugin = {\n  name: 'my-plugin',\n\n  setup() {\n    const foo = '1';\n\n    return {\n      // this is hook\n      afterBuild: () => {\n        //...\n      },\n    };\n  },\n};\n\n\n\nPlugin configuration items#\n\nIt is recommended to write the plugin as a function, so that the plugin can\nreceive configuration items via function entry.\n\n\n\ntype MyPluginOptions = {\n  foo: string;\n};\n\nconst myPlugin = (options: MyPluginOptions): CliPlugin => ({\n  name: 'my-plugin',\n\n  setup() {\n    console.log(options.foo);\n  },\n});\n","frontmatter":{"sidebar_position":2},"_filepath":"/Users/bytedance/github/targeral/modern-js/packages/document/module-doc/docs/en/plugins/guide/plugin-object.mdx","_relativePath":"en/plugins/guide/plugin-object.mdx"},{"id":29,"title":"Setup function","routePath":"/module-tools/en/plugins/guide/setup-function","lang":"en","toc":[{"text":"Plugin API objects","id":"plugin-api-objects","depth":2,"charIndex":174},{"text":"api.useAppContext","id":"apiuseappcontext","depth":3,"charIndex":784},{"text":"api.useResolvedConfigContext","id":"apiuseresolvedconfigcontext","depth":3,"charIndex":1308},{"text":"api.useHookRunners","id":"apiusehookrunners","depth":3,"charIndex":1801},{"text":"Asynchronous setup","id":"asynchronous-setup","depth":2,"charIndex":2122},{"text":"Life cycle hooks","id":"life-cycle-hooks","depth":2,"charIndex":2394}],"domain":"","content":"#\n\nIn the \"Plugin object\" section we know that the plug-in object contains a setup\nfunction that not only contains an api object parameter, but also returns a\nHooks object.\n\n\nPlugin API objects#\n\nThe setup function of the plugin will provide an api object parameter, and you\ncan call some of the methods provided on this object to get information about\nthe configuration, project context, etc.\n\nexport const myPlugin = (): CliPlugin => ({\n  name: 'my-plugin',\n\n  setup(api) {\n    // Get the original configuration of the application\n    const config = api.useConfigContext();\n    // Get the application runtime context\n    const appContext = api.useAppContext();\n    // Get the final configuration after resolving\n    const resolvedConfig = api.useResolvedConfigContext();\n  },\n});\n\n\n\napi.useAppContext#\n\nUsed to get project context information.\n\nconst useAppContext: () => IAppContext;\n\ninterface IAppContext {\n  appDirectory: string;\n  configFile: string | false;\n  packageName: string;\n  nodeModulesDirectory: string;\n  internalDirectory: string;\n  plugins: {\n    cli?: any;\n    server?: any;\n  }[];\n}\n\n\nINFO\n\nWe can see through the actual type file that there are other fields, but the\nonly ones that make sense for the module project at the moment are the above.\napi object other methods are the same.\n\n\napi.useResolvedConfigContext#\n\nUsed to get the final configuration after parsing.\n\nINFO\n\nIf you need to get the build-related final configuration, you need to use the\nbeforeBuild Hook.\n\nconst useResolvedConfigContext: () => NormalizedConfig;\n\ninterface NormalizedConfig {\n  buildConfig: PartialBuildConfig;\n  buildPreset: BuildPreset;\n  designSystem?: Record;\n  dev: Dev;\n  plugins: PluginConfig;\n  runtime: RuntimeConfig;\n  runtimeByEntries?: RuntimeByEntriesConfig;\n  _raw: UserConfig;\n}\n\n\n\napi.useHookRunners#\n\nUsed to get the executors of Hooks and trigger the execution of a specific Hook.\n\n\n\nexport const myPlugin = (): CliPlugin => ({\n  name: 'my-plugin',\n\n  async setup(api) {\n    const hookRunners = api.useHookRunners();\n    // trigger the afterBuild Hook\n    await hookRunners.afterBuild();\n  },\n});\n\n\n\nAsynchronous setup#\n\nThe setup of a CLI plugin can be an asynchronous function that performs\nasynchronous logic during the initialization process.\n\nexport const myPlugin = (): CliPlugin => ({\n  name: 'my-plugin',\n\n  async setup(api) {\n    await doSomething();\n  },\n});\n\n\n\nLife cycle hooks#\n\nWe know that the setup function returns a Hooks object, which can also be\nunderstood as an object with Module Tools lifecycle hooks.\n\nCurrently there are two main types of hooks.\n\n * build hooks: triggered only when the build command is executed to build the\n   source code product.\n * buildPlatform hook: triggered only when the build --platform command is\n   executed to generate other build products.\n * debug hooks: hooks that are triggered when running the dev command.\n\nSee the API documentation for a full list of lifecycle hooks.","frontmatter":{"sidebar_position":3},"_filepath":"/Users/bytedance/github/targeral/modern-js/packages/document/module-doc/docs/en/plugins/guide/setup-function.mdx","_relativePath":"en/plugins/guide/setup-function.mdx"},{"id":30,"title":"Overview","routePath":"/module-tools/en/plugins/official-list/overview","lang":"en","toc":[{"text":"Official Plugin","id":"official-plugin","depth":2,"charIndex":3}],"domain":"","content":"#\n\n\nOfficial Plugin#\n\n * @modern-js/plugin-module-import：Use SWC to provide the same ability as\n   babel-plugin-import.\n * @modern-js/plugin-module-banner：Add custom content, such as copyright\n   information, to the top and bottom of each JS and CSS file.\n * @modern-js/plugin-module-node-polyfill： Inject Polyfills of Node core modules\n   in the browser side.\n * @modern-js/plugin-module-polyfill：Inject polyfill for unsupported features\n   used in your code.\n * @modern-js/plugin-module-babel：Use Babel to transform your code.","frontmatter":{},"_filepath":"/Users/bytedance/github/targeral/modern-js/packages/document/module-doc/docs/en/plugins/official-list/overview.md","_relativePath":"en/plugins/official-list/overview.md"},{"id":31,"title":"Babel Plugin","routePath":"/module-tools/en/plugins/official-list/plugin-babel","lang":"en","toc":[{"text":"Quick start","id":"quick-start","depth":2,"charIndex":110},{"text":"Install","id":"install","depth":3,"charIndex":125},{"text":"Register","id":"register","depth":3,"charIndex":292},{"text":"Config","id":"config","depth":2,"charIndex":461}],"domain":"","content":"#\n\nTIP\n\nNormally, we don't need to use Babel to transform our code, this plugin is only\nused as a downgrade.\n\n\nQuick start#\n\n\nInstall#\n\n# npm\nnpm install @modern-js/plugin-module-babel -D\n\n# yarn\nyarn add @modern-js/plugin-module-babel -D\n\n# pnpm\npnpm add @modern-js/plugin-module-babel -D\n\n\n\nRegister#\n\nYou can install the plugin with the following command:\n\n\n\n\nexport default defineConfig({\n  plugins: [\n    moduleTools(),\n    modulePluginBabel(),\n  ],\n});\n\n\n\nConfig#\n\nSee babel options.\n\nHere is an example with @babel/preset-env configured\n\n\n\n\nexport default defineConfig({\n  plugins: [\n    moduleTools(),\n    modulePluginBabel({\n      presets: [['@babel/preset-env']],\n    }),\n  ],\n});\n","frontmatter":{},"_filepath":"/Users/bytedance/github/targeral/modern-js/packages/document/module-doc/docs/en/plugins/official-list/plugin-babel.md","_relativePath":"en/plugins/official-list/plugin-babel.md"},{"id":32,"title":"Banner Plugin","routePath":"/module-tools/en/plugins/official-list/plugin-banner","lang":"en","toc":[{"text":"Quick Start","id":"quick-start","depth":2,"charIndex":89},{"text":"Install","id":"install","depth":3,"charIndex":104},{"text":"Register","id":"register","depth":3,"charIndex":274},{"text":"Example","id":"example","depth":2,"charIndex":615},{"text":"Add copyright information at the top of a JS file","id":"add-copyright-information-at-the-top-of-a-js-file","depth":3,"charIndex":626},{"text":"Configuration","id":"configuration","depth":2,"charIndex":1127},{"text":"banner","id":"banner","depth":3,"charIndex":1286},{"text":"footer","id":"footer","depth":3,"charIndex":1426}],"domain":"","content":"#\n\nProvide the ability to inject content at the top and bottom of each JS and CSS\nfile.\n\n\nQuick Start#\n\n\nInstall#\n\n# npm\nnpm install @modern-js/plugin-module-banner -D\n\n# yarn\nyarn add @modern-js/plugin-module-banner -D\n\n# pnpm\npnpm add @modern-js/plugin-module-banner -D\n\n\n\nRegister#\n\nYou can install the plugin with the following command:\n\n\n\n\nexport default defineConfig({\n  plugins: [\n    moduleTools(),\n    modulePluginBanner({\n      banner: {\n        js: '//comment',\n        css: '/*comment*/',\n      },\n    }),\n  ],\n});\n\n\nTIP\n\nNote: CSS comments do not support the //comment syntax. Refer to \"CSS Comments\"\n\n\nExample#\n\n\nAdd copyright information at the top of a JS file#\n\n\n\n\n\nconst copyRight = `/*\n © Copyright 2020 xxx.com or one of its affiliates.\n * Some Sample Copyright Text Line\n * Some Sample Copyright Text Line\n * Some Sample Copyright Text Line\n * Some Sample Copyright Text Line\n * Some Sample Copyright Text Line\n * Some Sample Copyright Text Line\n*/`;\n\nexport default defineConfig({\n  plugins: [\n    moduleTools(),\n    modulePluginBanner({\n      banner: {\n        js: copyRight,\n      },\n    }),\n  ],\n});\n\n\n\nConfiguration#\n\n * Type\n\ntype BannerOptions = {\n  banner: {\n    js?: string;\n    css?: string;\n  };\n  footer?: {\n    js?: string;\n    css?: string;\n  };\n};\n\n\n\nbanner#\n\nAdd content at the top.\n\n * banner.js: Add content at the top of a JS file.\n * banner.css: Add content at the top of a CSS file.\n\n\nfooter#\n\nAdd content at the bottom.\n\n * footer.js: Add content at the bottom of a JS file.\n * footer.css: Add content at the bottom of a CSS file.","frontmatter":{},"_filepath":"/Users/bytedance/github/targeral/modern-js/packages/document/module-doc/docs/en/plugins/official-list/plugin-banner.md","_relativePath":"en/plugins/official-list/plugin-banner.md"},{"id":33,"title":"Import Plugin","routePath":"/module-tools/en/plugins/official-list/plugin-import","lang":"en","toc":[{"text":"Quick Start","id":"quick-start","depth":2,"charIndex":227},{"text":"Install","id":"install","depth":3,"charIndex":242},{"text":"Register","id":"register","depth":3,"charIndex":412},{"text":"Configurations","id":"configurations","depth":2,"charIndex":774},{"text":"pluginImport","id":"pluginimport","depth":3,"charIndex":855},{"text":"Notes","id":"notes","depth":2,"charIndex":1274}],"domain":"","content":"#\n\nUsing SWC provides the same ability and configuration as babel-plugin-import.\n\nTIP\n\nSince @modern-js/module-tools version >= v2.16.0, this plugin functionality is\nbuilt into Module Tools and is provided by transformImport.\n\n\nQuick Start#\n\n\nInstall#\n\n# npm\nnpm install @modern-js/plugin-module-import -D\n\n# yarn\nyarn add @modern-js/plugin-module-import -D\n\n# pnpm\npnpm add @modern-js/plugin-module-import -D\n\n\n\nRegister#\n\nIn Module Tools, you can register plugins in the following way:\n\n\n\n\nexport default defineConfig({\n  plugins: [\n    moduleTools(),\n    modulePluginImport({\n      pluginImport: [\n        {\n          libraryName: 'antd',\n          style: true,\n        },\n      ],\n    }),\n  ],\n});\n\n\nThis way we can use the ability of automatic import in Module Tools.\n\n\nConfigurations#\n\n * Type:\n\ntype Options = {\n  pluginImport?: ImportItem[];\n};\n\n\n\npluginImport#\n\n * Type: object[]\n\nThe elements of the array are configuration objects for babel-plugin-import,\nwhich can be referred to options。\n\nExample:\n\n\n\n\nexport default defineConfig({\n  plugins: [\n    moduleTools(),\n    modulePluginImport({\n      pluginImport: [\n        // babel-plugin-import`s options config\n        {\n          libraryName: 'foo',\n          style: true,\n        },\n      ],\n    }),\n  ],\n});\n\n\n\nNotes#\n\nSWC (Speedy Web Compiler) is written in Rust, and this plugin is based on SWC\nand ported from babel-plugin-import. The configuration options remain\nconsistent.\n\nSome configurations can accept functions, such as customName, customStyleName,\netc. These JavaScript functions are called by Rust through Node-API, which can\ncause some performance degradation.\n\nSimple function logic can be replaced by template language. Therefore, for\nconfigurations such as customName, customStyleName, etc., instead of passing\nfunctions, you can also pass a string as a template to replace the function,\nimproving performance.\n\nTemplate customName: 'foo/es/{{ member }}' is the same as customName: (member)\n=> `foo/es/${member}` , but template value has no performance overhead of\nNode-API.\n\nThe template used here is handlebars. There are some useful builtin tools, Take\nthe above import statement as an example:\n\n\n\n\nexport default defineConfig({\n  plugins: [\n    moduleTools(),\n    modulePluginImport({\n      pluginImport: [\n        {\n          libraryName: 'foo',\n          customName: 'foo/es/{{ kebabCase member }}',\n        },\n      ],\n    }),\n  ],\n});\n\n\nTransformed to:\n\n\n\n\nIn addition to kebabCase, there are cameraCase, snakeCase, upperCase and\nlowerCase can be used as well.","frontmatter":{},"_filepath":"/Users/bytedance/github/targeral/modern-js/packages/document/module-doc/docs/en/plugins/official-list/plugin-import.mdx","_relativePath":"en/plugins/official-list/plugin-import.mdx"},{"id":34,"title":"Node Polyfill Plugin","routePath":"/module-tools/en/plugins/official-list/plugin-node-polyfill","lang":"en","toc":[{"text":"Quick Start","id":"quick-start","depth":2,"charIndex":460},{"text":"Install","id":"install","depth":3,"charIndex":475},{"text":"Register","id":"register","depth":3,"charIndex":666},{"text":"Configurations","id":"configurations","depth":2,"charIndex":851},{"text":"exclude","id":"exclude","depth":3,"charIndex":956},{"text":"overrides","id":"overrides","depth":3,"charIndex":1153},{"text":"Node Polyfills","id":"node-polyfills","depth":2,"charIndex":1398},{"text":"Globals","id":"globals","depth":3,"charIndex":1416},{"text":"Modules","id":"modules","depth":3,"charIndex":1607},{"text":"Fallbacks","id":"fallbacks","depth":3,"charIndex":2108}],"domain":"","content":"#\n\nAbout Node Polyfill\n\nNormally, we don't need to use Node libs on the browser side. However, it is\npossible to use some Node libs when the code will run on both the Node side and\nthe browser side, and Node Polyfill provides browser versions of polyfills for\nthese Node libs.\n\nBy using the Node Polyfill plugin, Node core libs polyfills are automatically\ninjected into the browser-side, allowing you to use these modules on the browser\nside with confidence.\n\n\nQuick Start#\n\n\nInstall#\n\n# npm\nnpm install @modern-js/plugin-module-node-polyfill -D\n\n# yarn\nyarn add @modern-js/plugin-module-node-polyfill -D\n\n# pnpm\npnpm add @modern-js/plugin-module-node-polyfill -D\n\n\n\nRegister#\n\nIn Module Tools, you can register plugins in the following way:\n\n\n\n\nexport default defineConfig({\n  plugins: [\n    moduleTools(),\n    modulePluginNodePolyfill(),\n  ],\n});\n\n\n\nConfigurations#\n\n * Type:\n\ntype NodePolyfillOptions = {\n  exclude?: string[];\n  overrides?: Record;\n}\n\n\n\nexclude#\n\nExclude the Node Polyfill to be injected.\n\n\n\n\nexport default defineConfig({\n  plugins: [\n    moduleTools(),\n    modulePluginNodePolyfill({\n      exclude: ['console'],\n    }),\n  ],\n});\n\n\n\noverrides#\n\nOverride the built-in Node Polyfill.\n\n\n\n\nexport default defineConfig({\n  plugins: [\n    moduleTools(),\n    modulePluginNodePolyfill({\n      overrides: {\n        fs: path.join(__dirname, './custom-fs.js'),\n      }\n    }),\n  ],\n});\n\n\n\nNode Polyfills#\n\n\nGlobals#\n\n * Buffer\n * process\n * console\n\nWhen the above global variables are used directly in code, the corresponding\npolyfill will be injected.\n\nconst bufferData = Buffer.from('xxxx');\n\n\n\nModules#\n\n * assert\n * buffer\n * console\n * constants\n * crypto\n * domain\n * events\n * http\n * https\n * os\n * path\n * punycode\n * process\n * querystring\n * stream\n * _stream_duplex\n * _stream_passthrough\n * _stream_readable\n * _stream_transform\n * _stream_writable\n * string_decoder\n * sys\n * timers\n * tty\n * url\n * util\n * vm\n * zlib\n\nWhen the above module is referenced in code via import / require syntax, the\ncorresponding polyfill will be injected.\n\n\n\nconst bufferData = Buffer.from('xxxx');\n\n\n\nFallbacks#\n\n * child_process\n * cluster\n * dgram\n * dns\n * fs\n * module\n * net\n * readline\n * repl\n * tls\n\nCurrently there is no polyfill for the above modules on the browser side, so\nwhen you import the above modules, it will automatically fallback to an empty\nobject.\n\n\n\nconsole.log(fs); // -> {}\n","frontmatter":{},"_filepath":"/Users/bytedance/github/targeral/modern-js/packages/document/module-doc/docs/en/plugins/official-list/plugin-node-polyfill.md","_relativePath":"en/plugins/official-list/plugin-node-polyfill.md"},{"id":35,"title":"Polyfill Plugin","routePath":"/module-tools/en/plugins/official-list/plugin-polyfill","lang":"en","toc":[{"text":"Quick start","id":"quick-start","depth":2,"charIndex":497},{"text":"Install","id":"install","depth":3,"charIndex":512},{"text":"Register","id":"register","depth":3,"charIndex":688},{"text":"Config","id":"config","depth":2,"charIndex":869},{"text":"targets","id":"targets","depth":3,"charIndex":938}],"domain":"","content":"#\n\nTIP\n\nNormally, we don't need to inject polyfill for npm packages, this step should be\ndone on the web application framework side, but in some scenarios we need to\ninject polyfill in order to make our library run directly in low version\nbrowsers.\n\nNote that this plugin does not transform your code syntax, it only injects\npolyfill for unsupported functions used in your code, importing them as normal\nfunctions instead of polluting the global. You need to install the core-js-pure\ndependency.\n\n\nQuick start#\n\n\nInstall#\n\n# npm\nnpm install @modern-js/plugin-module-polyfill -D\n\n# yarn\nyarn add @modern-js/plugin-module-polyfill -D\n\n# pnpm\npnpm add @modern-js/plugin-module-polyfill -D\n\n\n\nRegister#\n\nIn Module Tools, you can register plugins in the following way:\n\n\n\n\nexport default defineConfig({\n  plugins: [\n    moduleTools(),\n    modulePluginPolyfill(),\n  ],\n});\n\n\n\nConfig#\n\n * Type\n\ntype options = {\n  targets?: Record | string;\n}\n\n\n\ntargets#\n\nSee Babel target.\n\nThis is a example.\n\n\n\n\nexport default defineConfig({\n  plugins: [\n    moduleTools(),\n    modulePluginPolyfill({\n      targets: \"> 0.25%, not dead\"\n    }),\n  ],\n});\n","frontmatter":{},"_filepath":"/Users/bytedance/github/targeral/modern-js/packages/document/module-doc/docs/en/plugins/official-list/plugin-polyfill.md","_relativePath":"en/plugins/official-list/plugin-polyfill.md"}]