From ef8154d734e55503f1647ea28a9d3219fdfc9164 Mon Sep 17 00:00:00 2001 From: skyclouds2001 <95597335+skyclouds2001@users.noreply.github.com> Date: Sun, 6 Oct 2024 19:25:21 +0800 Subject: [PATCH] fix links --- .../react_getting_started/index.md | 8 ++++---- .../vue_getting_started/index.md | 2 +- .../introducing_complete_toolchain/index.md | 8 ++++---- .../understanding_client-side_tools/overview/index.md | 2 +- .../package_management/index.md | 4 ++-- .../api/declarativenetrequest/headerinfo/index.md | 2 +- .../web/api/web_workers_api/using_web_workers/index.md | 2 +- files/en-us/web/api/worker/worker/index.md | 2 +- 8 files changed, 15 insertions(+), 15 deletions(-) diff --git a/files/en-us/learn/tools_and_testing/client-side_javascript_frameworks/react_getting_started/index.md b/files/en-us/learn/tools_and_testing/client-side_javascript_frameworks/react_getting_started/index.md index 492b0dd1684bfaa..a553aa8812a4f37 100644 --- a/files/en-us/learn/tools_and_testing/client-side_javascript_frameworks/react_getting_started/index.md +++ b/files/en-us/learn/tools_and_testing/client-side_javascript_frameworks/react_getting_started/index.md @@ -59,7 +59,7 @@ While React _can_ be used for [small pieces of an interface](https://react.dev/l In addition, many of the developer-experience benefits of a React app, such as writing interfaces with JSX, require a compilation process. Adding a compiler like Babel to a website makes the code on it run slowly, so developers often set up such tooling with a build step. React arguably has a heavy tooling requirement, but it can be learned. -This article is going to focus on the use case of using React to render the entire user interface of an application with the support of [Vite](https://vitejs.dev/), a modern front-end build tool. +This article is going to focus on the use case of using React to render the entire user interface of an application with the support of [Vite](https://vite.dev/), a modern front-end build tool. ## How does React use JavaScript? @@ -136,7 +136,7 @@ See the following for more information: - ["About npm" on the npm blog](https://docs.npmjs.com/about-npm/) - ["Introducing npx" on the npm blog](https://blog.npmjs.org/post/162869356040/introducing-npx-an-npm-package-runner) -- [Vite's documentation](https://vitejs.dev/guide/) +- [Vite's documentation](https://vite.dev/guide/) ### Initializing your app @@ -232,7 +232,7 @@ function App() { return ( <>
- + Vite logo @@ -290,7 +290,7 @@ function App() { return ( <>
- + Vite logo diff --git a/files/en-us/learn/tools_and_testing/client-side_javascript_frameworks/vue_getting_started/index.md b/files/en-us/learn/tools_and_testing/client-side_javascript_frameworks/vue_getting_started/index.md index 0ce93a87c05a551..5e6518f22820ffc 100644 --- a/files/en-us/learn/tools_and_testing/client-side_javascript_frameworks/vue_getting_started/index.md +++ b/files/en-us/learn/tools_and_testing/client-side_javascript_frameworks/vue_getting_started/index.md @@ -135,7 +135,7 @@ If everything went successfully, the CLI should have created a series of files a - `package.json`: This file contains the list of dependencies for your project, as well as some metadata and `eslint` configuration. - `yarn.lock`: If you chose `yarn` as your package manager, this file will be generated with a list of all the dependencies and sub-dependencies that your project needs. - `jsconfig.json`: This is a config file for [Visual Studio Code](https://code.visualstudio.com/docs/languages/jsconfig) and gives context for VS Code on your project structure and assists auto-completion. -- `vite.config.js`: This is the configuration file for the [Vite](https://vitejs.dev/) development server that builds and serves your project on your local machine. +- `vite.config.js`: This is the configuration file for the [Vite](https://vite.dev/) development server that builds and serves your project on your local machine. The Vite server watches source files for changes and can hot-reload the project while you make changes. - `public`: This directory contains static assets that are published during build. - `favicon.ico`: This is the favicon for your app. Currently, it's the Vue logo. diff --git a/files/en-us/learn/tools_and_testing/understanding_client-side_tools/introducing_complete_toolchain/index.md b/files/en-us/learn/tools_and_testing/understanding_client-side_tools/introducing_complete_toolchain/index.md index 91f1515e7b25439..ef2ce80c65751ac 100644 --- a/files/en-us/learn/tools_and_testing/understanding_client-side_tools/introducing_complete_toolchain/index.md +++ b/files/en-us/learn/tools_and_testing/understanding_client-side_tools/introducing_complete_toolchain/index.md @@ -45,7 +45,7 @@ In this article we're going to use the following tools and features: - The latest built-in JavaScript features (at the time of writing), such as [`import`](/en-US/docs/Web/JavaScript/Reference/Statements/import). - Useful development tools such as [Prettier](https://prettier.io/) for formatting and [ESLint](https://eslint.org/) for linting. - [PostCSS](https://postcss.org/) to provide CSS nesting capabilities. -- [Vite](https://vitejs.dev/) to build and minify our code, and to write a bunch of configuration file content automatically for us. +- [Vite](https://vite.dev/) to build and minify our code, and to write a bunch of configuration file content automatically for us. - [GitHub](/en-US/docs/Learn/Tools_and_testing/GitHub) to manage our source code control as well as to eventually deploy our site (using GitHub Pages). You may not be familiar with all the above features and tools or what they are doing, but don't panic — we'll explain each part as we move through this article. @@ -353,15 +353,15 @@ export default defineConfig({ }); ``` -Read the [Vite documentation](https://vitejs.dev/guide/) for more information on how to configure Vite. Because our site is deployed on GitHub pages, it will be hosted at `https://your-username.github.io/your-repo-name`, so you should set the `base` option according to your GitHub repository's name—but you can always adjust it later when we get to [deployment](/en-US/docs/Learn/Tools_and_testing/Understanding_client-side_tools/Deployment). +Read the [Vite documentation](https://vite.dev/guide/) for more information on how to configure Vite. Because our site is deployed on GitHub pages, it will be hosted at `https://your-username.github.io/your-repo-name`, so you should set the `base` option according to your GitHub repository's name—but you can always adjust it later when we get to [deployment](/en-US/docs/Learn/Tools_and_testing/Understanding_client-side_tools/Deployment). ### CSS transformation Our CSS may also be using syntax not understood by browsers. For example, you may use a syntax that was only implemented in the last few browser versions, which means older browsers will fail on it and display broken style. We can use a tool to transform our CSS into a format that all browsers that we target can understand. -[PostCSS](https://postcss.org/) is a CSS postprocessor tool. Compared to build tools like [Sass](https://sass-lang.com/), PostCSS is intended to write _standard_ CSS (that is, CSS syntax that may get into browsers one day), while Sass is a custom language by itself that compiles to CSS. PostCSS is closer to the web and has a much lower learning curve. [Vite supports PostCSS by default](https://vitejs.dev/guide/features.html#postcss), so you just need to [configure PostCSS](https://github.com/postcss/postcss#usage) if you want to compile any features. Check out the [cssdb](https://preset-env.cssdb.org/features/) for what features are supported. +[PostCSS](https://postcss.org/) is a CSS postprocessor tool. Compared to build tools like [Sass](https://sass-lang.com/), PostCSS is intended to write _standard_ CSS (that is, CSS syntax that may get into browsers one day), while Sass is a custom language by itself that compiles to CSS. PostCSS is closer to the web and has a much lower learning curve. [Vite supports PostCSS by default](https://vite.dev/guide/features.html#postcss), so you just need to [configure PostCSS](https://github.com/postcss/postcss#usage) if you want to compile any features. Check out the [cssdb](https://preset-env.cssdb.org/features/) for what features are supported. -For our purposes, we are going to demonstrate another CSS transformation: [CSS modules](https://vitejs.dev/guide/features.html#css-modules). It is one of the ways to achieve _CSS modularization_. Remember that CSS selectors are all global, so if you have a class name like `.button`, all elements with the class name `button` will be styled the same way. This often leads to naming conflicts — imagine all your JavaScript variables being defined at the global scope! CSS modules solve this problem by making the class name unique to the pages that use them. To understand how it works, after you've downloaded the source code, you can check how we use the `.module.css` files, and also read the [CSS modules documentation](https://github.com/css-modules/css-modules). +For our purposes, we are going to demonstrate another CSS transformation: [CSS modules](https://vite.dev/guide/features.html#css-modules). It is one of the ways to achieve _CSS modularization_. Remember that CSS selectors are all global, so if you have a class name like `.button`, all elements with the class name `button` will be styled the same way. This often leads to naming conflicts — imagine all your JavaScript variables being defined at the global scope! CSS modules solve this problem by making the class name unique to the pages that use them. To understand how it works, after you've downloaded the source code, you can check how we use the `.module.css` files, and also read the [CSS modules documentation](https://github.com/css-modules/css-modules). Although this stage of our toolchain can be quite painful, because we've chosen a tool that purposely tries to reduce configuration and complexity, there's really nothing more we need to do during the development phase. Modules are correctly imported, nested CSS is correctly transformed to "regular CSS", and our development is unimpeded by the build process. diff --git a/files/en-us/learn/tools_and_testing/understanding_client-side_tools/overview/index.md b/files/en-us/learn/tools_and_testing/understanding_client-side_tools/overview/index.md index aec08b4ff0f6a77..ee3f70a784aefe4 100644 --- a/files/en-us/learn/tools_and_testing/understanding_client-side_tools/overview/index.md +++ b/files/en-us/learn/tools_and_testing/understanding_client-side_tools/overview/index.md @@ -120,7 +120,7 @@ Generally, web development is thought of as three languages: [HTML](/en-US/docs/ 3. Optimization. This is provided by _bundlers_, which are tools that get your code ready for production, for example by "[tree-shaking](/en-US/docs/Glossary/Tree_shaking)" to make sure only the parts of your code libraries that you are actually using are put into your final production code, or "[minifying](/en-US/docs/Glossary/Minification)" to remove all the whitespace in your production code, making it as small as possible before it is uploaded to a server. For example: - [Webpack](https://webpack.js.org/) has been the most popular bundler for a long time, featuring a huge number of plugins and a powerful configuration system. However, it is also known for being quite complex to set up, and is slow compared to more modern alternatives. - - [Vite](https://vitejs.dev/) is a more modern build tool that is popular for its speed, simplicity, and richness of features. + - [Vite](https://vite.dev/) is a more modern build tool that is popular for its speed, simplicity, and richness of features. ### Post development diff --git a/files/en-us/learn/tools_and_testing/understanding_client-side_tools/package_management/index.md b/files/en-us/learn/tools_and_testing/understanding_client-side_tools/package_management/index.md index 9e82f830d71574b..ab271701fdfef49 100644 --- a/files/en-us/learn/tools_and_testing/understanding_client-side_tools/package_management/index.md +++ b/files/en-us/learn/tools_and_testing/understanding_client-side_tools/package_management/index.md @@ -78,9 +78,9 @@ What is important is that you ensure you've chosen the best registry for you. Ma Let's run through an example to get you started with using a package manager and registry to install a command line utility. -We will use [Vite](https://vitejs.dev/) to create a blank website. In the next article, we will expand on the toolchain to include more tools and show you how to deploy the site. +We will use [Vite](https://vite.dev/) to create a blank website. In the next article, we will expand on the toolchain to include more tools and show you how to deploy the site. -Vite provides some [init templates](https://vitejs.dev/guide/#scaffolding-your-first-vite-project), with all necessary dependencies and configurations, to get you started quickly in a real project. For demonstration, we will configure one from scratch, using the [React template](https://github.com/vitejs/vite/tree/main/packages/create-vite/template-react) as a reference. +Vite provides some [init templates](https://vite.dev/guide/#scaffolding-your-first-vite-project), with all necessary dependencies and configurations, to get you started quickly in a real project. For demonstration, we will configure one from scratch, using the [React template](https://github.com/vitejs/vite/tree/main/packages/create-vite/template-react) as a reference. ### Setting up the app as an npm package diff --git a/files/en-us/mozilla/add-ons/webextensions/api/declarativenetrequest/headerinfo/index.md b/files/en-us/mozilla/add-ons/webextensions/api/declarativenetrequest/headerinfo/index.md index e00e70cace372cd..2bf3bdded142b10 100644 --- a/files/en-us/mozilla/add-ons/webextensions/api/declarativenetrequest/headerinfo/index.md +++ b/files/en-us/mozilla/add-ons/webextensions/api/declarativenetrequest/headerinfo/index.md @@ -15,7 +15,7 @@ When used in the condition responseHeaders, the rule matches if the request matc Each object describes one header to match or exclude. To check multiple headers, multiple objects can be specified in these arrays, or across multiple rules. -> [!NOTE] Matching by headers is a relatively new feature. Make sure to feature-detect its availability before relying on it. While some browsers ignore the complete rule when an unrecognized condition is present, Chrome 121 until 127 applied the whole rule while ignoring the `responseHeaders` condition. This could result in matching more requests than intended, see [Chromium issue 347186592](https://issues.chromium.org/issues/347186592). +> [!NOTE] Matching by headers is a relatively new feature. Make sure to feature-detect its availability before relying on it. While some browsers ignore the complete rule when an unrecognized condition is present, Chrome 121 until 127 applied the whole rule while ignoring the `responseHeaders` condition. This could result in matching more requests than intended, see [Chromium issue 347186592](https://crbug.com/347186592). ## Type diff --git a/files/en-us/web/api/web_workers_api/using_web_workers/index.md b/files/en-us/web/api/web_workers_api/using_web_workers/index.md index de669f1a8511dc1..857f7abb74afe63 100644 --- a/files/en-us/web/api/web_workers_api/using_web_workers/index.md +++ b/files/en-us/web/api/web_workers_api/using_web_workers/index.md @@ -53,7 +53,7 @@ const myWorker = new Worker("worker.js"); ``` > [!NOTE] -> Bundlers, including [Webpack](https://webpack.js.org/guides/web-workers/), [Vite](https://vitejs.dev/guide/features.html#web-workers), and [Parcel](https://parceljs.org/languages/javascript/#web-workers), recommend passing URLs that are resolved relative to [`import.meta.url`](/en-US/docs/Web/JavaScript/Reference/Operators/import.meta#url) to the `Worker()` constructor. For example: +> Bundlers, including [Webpack](https://webpack.js.org/guides/web-workers/), [Vite](https://vite.dev/guide/features.html#web-workers), and [Parcel](https://parceljs.org/languages/javascript/#web-workers), recommend passing URLs that are resolved relative to [`import.meta.url`](/en-US/docs/Web/JavaScript/Reference/Operators/import.meta#url) to the `Worker()` constructor. For example: > > ```js > const myWorker = new Worker(new URL("worker.js", import.meta.url)); diff --git a/files/en-us/web/api/worker/worker/index.md b/files/en-us/web/api/worker/worker/index.md index 28f2c4bb233231d..3c5ea932216bd64 100644 --- a/files/en-us/web/api/worker/worker/index.md +++ b/files/en-us/web/api/worker/worker/index.md @@ -27,7 +27,7 @@ new Worker(url, options) - : A string representing the URL of the script the worker will execute. It must obey the same-origin policy. The URL is resolved relative to the current HTML page's location. > [!NOTE] - > Bundlers, including [Webpack](https://webpack.js.org/guides/web-workers/), [Vite](https://vitejs.dev/guide/features.html#web-workers), and [Parcel](https://parceljs.org/languages/javascript/#web-workers), recommend passing URLs that are relative to [`import.meta.url`](/en-US/docs/Web/JavaScript/Reference/Operators/import.meta#url) to the `Worker()` constructor. For example: + > Bundlers, including [Webpack](https://webpack.js.org/guides/web-workers/), [Vite](https://vite.dev/guide/features.html#web-workers), and [Parcel](https://parceljs.org/languages/javascript/#web-workers), recommend passing URLs that are relative to [`import.meta.url`](/en-US/docs/Web/JavaScript/Reference/Operators/import.meta#url) to the `Worker()` constructor. For example: > > ```js > const myWorker = new Worker(new URL("worker.js", import.meta.url));