eddev 0.2.27 → 0.2.30

package/docs_old/docs/how-to/2.deployment.md

@@ -1,31 +0,0 @@
-# Deployment
-
-There are some prerequisites for setting up deployment.
-
-1. You've got an SSH key set up on your computer, which has been added to both Github and Flywheel. You only need to do this once for your computer.
-2. You've set up the site on Flywheel already, and completed an initial push using Local Sync.
-
-Assuming the above prerequisites are met, setting up deployment is easy!
-
-1. Grab the Flywheel SSH user for your site.
-   1. On the [Flywheel Dashboard](https://app.getflywheel.com/sites), locate the relevant site.
-   2. Click the 'Advanced' tab.
-   3. Copy the user component from the 'Connect via SSH' section.
-      (For example, if the connection string is `ssh team+ed-digital+the-yards@ssh.getflywheel.com`), the value is `team+ed-digital+the-yards`.
-2. Grab your private key.
-   1. Assuming you're using your default private key, and that it's in the correct format already, you can just run `cat ~/.ssh/id_rsa | pbcopy` in your terminal to copy this directly to your clipboard.
-3. Paste the secrets into the Github repo's 'Secrets' panel.
-   1. Open the repo on Github, and click Settings -> Secrets.
-   2. Add a new secret called `SSH_USER` and paste in the value from step 1. Save it!
-   3. Add a new secret called `PRIVATE_KEY` and paste in the value from step 2. Save it!
-4. Finally, rename `.github/workflows/main.yaml.disabled` to `.github/workflows/main.yaml` and commit/push the results.
-   ```
-   mv .github/workflows/main.yaml.disabled .github/workflows/main.yaml
-   git commit -am "Enable Github Action deployment"
-   git push
-   ```
-5. Monitor the 'Actions' tab on your Github repo page to ensure that the first deployment succeeded.
-
-:::tip warning
-Your first deploy might fail to run at the 'Install Dependencies' step. Try running 'Re-run all jobs'.
-:::

package/docs_old/docs/how-to/3.menus.md

@@ -1,72 +0,0 @@
-# Menus
-
-For simplicities sake, all menus are pre-loaded in the starter theme's `views/_app.graphql`. It looks something like this:
-
-```graphql title="views/_app.graphql"
-query CommonData {
-  menus {
-    nodes {
-      menuItems {
-        nodes {
-          ...MenuItemFields
-        }
-      }
-      locations
-      slug
-      name
-    }
-  }
-}
-
-fragment MenuItemFields on MenuItem {
-  label
-  title
-  target
-  url
-  cssClasses
-  childItems {
-    nodes {
-      label
-      title
-      target
-      url
-      cssClasses
-    }
-  }
-}
-```
-
-The fragment is used there so that it's easy to grab TypeScript types for the menu data structure.
-
-There's also a `backend/menus.php` file, which has a call to `register_nav_menus` function call, which sets up 'menu locations'. If you need more than just one menu, you can add them there.
-
-```php
-register_nav_menus([
-  'main' => 'Main Menu',
-  'footer' => 'Footer Menu'
-]);
-```
-
-The starter theme also comes with a `components/atoms/Menu.tsx` component. It's included as a component which you can tailor to your needs.
-
-To use the menu component, you'll need to specify the menu location which you defined in PHP. Assuming you've got `yarn dev` running, the menu locations will auto-complete with TypeScript.
-
-```tsx
-<Menu location="Main">
-```
-
-It's recommended that if you need to stylise or customise the Menu, that you kinda keep that file nice and generic, and create a new component which uses the `Menu` component as a base. (Or alternatively, you can always copy/paste the `Menu` code into your new component.)
-
-```tsx title="components/atoms/MyCoolMenu.tsx
-import { Menu } from "@components/atoms/Menus"
-
-export const MyCoolMenu = styled(Menu, {
-  display: "flex",
-  li: {
-    marginLeft: "20px",
-    a: {
-      fontFamily: '"Comic Sans"',
-    },
-  },
-})
-```

package/docs_old/docs/how-to/4.options-pages.md

@@ -1,41 +0,0 @@
-# Options Pages
-
-You can create an 'Options Page' on the WordPress sidebar to create a space for global ACF fields.
-
-Creating and consuming an options page can be completed in a few steps:
-
-1. Create a new Options Page — check out `backend/options.php` for some example code, noting that `show_in_graphql` must be set to `true`.
-2. Create a new ACF field group, with the fields you need.
-   1. Set the Location Rule to `Options Page` `is equal to` `<your new options page>`.
-   2. Make sure `Show in GraphQL` is checked.
-   3. Set `GraphQL Field Name` to something short and sweet, using pascalCase, eg `myOptions`.
-3. Check the GraphiQL IDE, and look for a root-level field with a similar name to the `menu_slug` defined in your PHP, code, eg. `themeGeneralSettings`. It should have a child field with you `GraphQL Field Name`, which contains your settings!
-
-The PHP code should look something like this:
-
-```php
-acf_add_options_page([
-  'page_title' 	=> 'Theme Settings',
-  'menu_title'	=> 'Theme Settings',
-  'menu_slug' 	=> 'theme-general-settings',
-  'capability'	=> 'edit_posts',
-  'redirect'		=> false,
-  'show_in_graphql' => true
-]);
-```
-
-Assuming that all worked, you can then query these fields in an `.graphql` file. If it needs to be globally accessible, you can add it to the `_app.graphql` file, and access it using the `useAppData` hook. It'll even be typed with TypeScript.
-
-```graphql title="views/_app.graphql"
-query AppData {
-  themeGeneralSettings {
-    myOptions {
-      footerText
-    }
-  }
-}
-```
-
-```tsx
-const footerText = useAppData((data) => data?.themeGeneralSettings?.myOptions?.footerText)
-```

package/docs_old/docs/how-to/5.bundle-size.md

@@ -1,177 +0,0 @@
-# Bundle Size Tips
-
-## Inspecting Bundle Size
-
-You can quite easily see the production size of your app by running:
-
-```bash
-yarn build
-```
-
-![Webpack Result](./img/bundle-webpack-before.png)
-
-Above, we can see that the bundle size is 1.34mb, which is quite large. The note from Webpack says that we should aim for 244kb, which is really quite small. When we eventually move to serverless (via Vercel) for production frontends, we'll certainly aim for this smaller size. For now, with WordPress hosting, 600-700kb is fine. React itself takes up a bit of space on it's own.
-
-Let's dig deeper into why the bundle is so large.
-
-Our compile system includes the official [Webpack Bundle Analyzer](https://www.npmjs.com/package/webpack-bundle-analyzer) plugin. You can get a detailed analysis of the bundle size using the following:
-
-```bash
-yarn build
-open dist/frontend/bundle-report.html
-```
-
-Your browser will launch the bundle report, which will look something like this.
-
-![Bundle Size Output](./img/bundle-analysis-before.png)
-
-You can see in the example above, that `hls.js` and `moment` + `moment-timezone` are taking up _a lot_ of the bundle size.
-
-What can we do about this?
-
-## Choosing better libraries
-
-In the example above, `moment` is taking up SO much space, for something that is so simple. There are much simpler and smaller libraries that can be used instead.
-
-- If all you want is date formatting, check out `date-fns` — which provides a nifty date formatting function. The library is tree-shakable, meaning only the functions from that library you actually use in your code will be included in the bundle. [date-fns →](https://date-fns.org/)
-- If you need something a little more powerful, or if you need something related to timezones, check out `luxon`, which is made by the same team that created `moment`. It's a much lighter alternative, because even though it supports timezones, it uses native browser APIs, instead of bundling info on every timezone/locale. [Luxon →](https://moment.github.io/luxon/index.html#/?id=luxon)
-  - (ps. Luxon doesn't come with TypeScript types, but you can install them using `yarn add --dev @types/luxon`)
-
-It's always worth reconsidering the libraries we choose, looking for the most modern libraries for certain functions.
-
-## Dynamic imports
-
-Next up is `hls.js`. It's a library that provides a simple way to load and play HLS streams. It's not huge, but we probably don't need to include it in the main bundle.
-
-Say we have the following code:
-
-```tsx
-import Hls from "hls.js"
-
-// ...
-
-useEffect(() => {
-  const video = ref.current!
-  if (src) {
-    if (video.canPlayType("application/vnd.apple.mpegurl")) {
-      // HLS is already supported natively by this browser
-      video.src = props.url
-    } else {
-      // HLS is not supported by the browser. Use Hls.js instead!
-      const hls = new Hls()
-      hls.loadSource(props.url!)
-      hls.attachMedia(video)
-      return () => {
-        hls.destroy()
-      }
-    }
-  }
-}, [src])
-```
-
-We can quite easily refactor this code to use dynamic imports, which will automatically split that library into it's own file, which will be imported separately only if/when it's needed. If we still need TypeScript types for the module, we can also use `import type` syntax, which will only import the types for TypeScript's sake, and not the module itself.
-
-```tsx
-import type Hls from "hls.js"
-
-// ...
-
-useEffect(() => {
-  const video = ref.current!
-  if (props.url) {
-    if (video.canPlayType("application/vnd.apple.mpegurl")) {
-      // HLS is already supported natively by this browser
-      video.src = props.url
-    } else {
-      // HLS is not supported by the browser. Use Hls.js instead!
-      // Declare a reference to the object, so we can can still destroy it when the component transitions out
-      let hls: Hls
-      import("hls.js").then(({ default: Hls }) => {
-        // hls.js has been successfully dynamically imported.
-        // Assign to the `hls` variable, so that it can be destroyed properly
-        hls = new Hls()
-        hls.loadSource(props.url!)
-        hls.attachMedia(video)
-      })
-      return () => {
-        // Destroy the hls video, as long as it was created in the first place
-        if (hls) {
-          hls.destroy()
-        }
-      }
-    }
-  }
-}, [props.url])
-```
-
-## Dynamicly imported components
-
-Similar to Next's `next/dynamic` [(link)](https://nextjs.org/docs/advanced-features/dynamic-import), we have our own `eddev/dynamic` function. This allows you dynamically load components from the `components/*` directory using dynamic imports.
-
-```tsx title="blocks/homepage/some-block.tsx"
-import { dynamic } from "eddev/dynamic"
-
-const MyDynamicComponent = dynamic(() => import("@components/something/my-dynamic-component"))
-
-export default defineBlock("homepage/some-block", () => {
-  return (
-    <div>
-      <p>I appear instantly</p>
-      <MyDynamicComponent fallback={<div>Loading...</div>} />
-    </div>
-  )
-})
-```
-
-All the same props from `MyDynamicComponent` are available, and the fallback (which is optional) is added as a prop by the `dynamic` function. It'll show the fallback while the component is loading.
-
-When using this feature, you may notice a flash while the component is being loaded, since your page will actually render without the dynamic component first. This means that it may not always be suitable if the component is typically "above the fold". You may want to consider showing a placeholder div, and/or fading in the component using an animation once it's loaded.
-
-It's also important to note that the dynamic function expects (by default), a `default` export. Normally, we prefer to export named components, but in this case, `default` is good.
-
-```tsx title="components/something/my-dynamic-component.tsx"
-// BAD: export function MyDynamicComponent() {}
-// GOOD:
-export default function MyDynamicComponent() {
-  return <div>I'm a dynamic component!</div>
-}
-```
-
-Internally, we use `@loadable/components` — you can see other options for `dynamic` via their [docs](https://loadable-components.com/). Next also uses this library!
-
-## Dynamically imported blocks
-
-The `eddev/dynamic` function requires a tiny bit of boilerplate to get going. If you'd like to make a whole _block_ load dynamically, it's even easier. Note though that you wont be able to show a loading fallback.
-
-Just add `Dynamic: true` to your block header comment — the compiler will spot this, and automatically turn it into a dynamic component. That's it!
-
-```tsx title="blocks/homepage/some-block.tsx"
-/**
- * Title: Some Block
- * Description: A block that does something cool
- * Category: common
- * Icon: book-alt
- * Keywords: post
- * Templates: default
- * Types: page
- * Mode: preview
- * Supports multiple: true
- * Tags: root
- * Child Tags: none
- * Dynamic: true
- */
-```
-
-^ The last line is the important part. You can read more about dynamic blocks [here](../gutenberg/dynamic-blocks).
-
-## Validating the changes
-
-In the top sections above, we swapped from `moment` to `luxon`, and we also made `hls.js` a dynamic import.
-
-After running `yarn build` again, and checking out the visualizer, we can see that these two small changes have reduced our main bundle size by **HALF**.
-
-![Webpack Result](./img/bundle-webpack-after.png)
-
-![Bundle Size Output](./img/bundle-analysis-after.png)
-
-We could take this even further if we wanted, by making any blocks which use Swiper dynamic blocks, as discussed above.

package/docs_old/docs/how-to/6.favicons.md

@@ -1,82 +0,0 @@
-# Favicons
-
-Since `eddev@0.2.0`, favicons are automatically included in every page, in both serverless and WordPress. All you need to do is export the icons straight from Figma!
-
-## Exporting the icons
-
-1. Navigate to the **🍒 oGraph & Icons** page in Figma
-2. Select all the icons on the right
-3. Activate the **Export** tab in the sidebar
-4. Export with default settings to the `assets` folder in your theme.
-5. Run `yarn dev` to regenerate the `favicon.ico` file, which is used as a fallback. The `<head>` is published automatically.
-
-:::tip
-See the bottom of this page for screenshots!
-:::
-
-## `favicon.ico`
-
-When you run `yarn dev` or `yarn build`, a `favicon.ico` is automatically generated for you!
-
-It uses the uses the pattern `assets/favicon/favicon-*.png`, which usually means it'll be composed using `favicon-16x16.png`, `favicon-32x32.png` and `favicon-96x96.png`.
-
-## Light & Dark Mode Icons
-
-Not all browsers support SVG favicons, but they're a great way to optionally support light/dark mode. You can right-click and 'Copy as SVG', and then add appropriate styling. Save to `assets/favicon/favicon.svg`, and it'll automatically be added to the `<head>` tag.
-
-See below for an example:
-
-```svg title="assets/favicon/favicon.svg"
-<svg width="16" height="16" viewBox="0 0 16 16" fill="none"
-  xmlns="http://www.w3.org/2000/svg">
-  <style>
-    path {
-      fill: #000000;
-    }
-    @media (prefers-color-scheme: dark) {
-      path {
-        fill: #ffffff;
-      }
-    }
-  </style>
-  <path d="..." />
-</svg>
-```
-
-## Meta Tags
-
-The appropriate `<link />` tags are automatically added to your `<head>` tag, so you don't need to worry about it. Note that these tags only appear if they're found in the correct folder (`assets/favicon/`).
-
-## Filenames
-
-The following files are expected to be found. Note that if they are missing, there are no errors!
-
-```
-/assets/favicons/favicon.svg
-/assets/favicons/120x120.png
-/assets/favicons/128x128.png
-/assets/favicons/196x196.png
-/assets/favicons/apple-touch-icon-120x120.png
-/assets/favicons/apple-touch-icon-152x152.png
-/assets/favicons/apple-touch-icon-167x167.png
-/assets/favicons/apple-touch-icon-180x180.png
-/assets/favicons/favicon-16x16.png
-/assets/favicons/favicon-32x32.png
-/assets/favicons/favicon-96x96.png
-/assets/favicons/windows-270x270.png
-/assets/favicons/windows-70x70.png
-```
-
-## Screenshots of export steps
-
-Select all the icons, skipping the labels:
-
-![Figure A. Select all icons](./img/favicon-figma.png)
-
-Export your selection:
-
-![Figure B. Export them](./img/favicon-figma-export.png)
-
-Your codebase should look like this after you've exported them. Note that if you instead see an `App icon` folder, you should rename this to `favicon` and ensure that it matches as below:
-
-![Figure C. You should now have a 'favicons' folder](./img/favicon-codebase.png)

package/docs_old/docs/how-to/_category_.json

@@ -1,4 +0,0 @@
-{
-  "label": "🧐 How To",
-  "position": 20
-}

package/docs_old/docs/intro.md

@@ -1,7 +0,0 @@
----
-sidebar_position: 1
----
-
-# 👋 Intro
-
-Welcome! Use the sidebar on the left to find what you're looking for.

package/docs_old/docs/known-issues.md

@@ -1,8 +0,0 @@
----
-sidebar_position: 100
----
-
-# Known Issues
-
-- Fragments from `/queries/fragments` don't run in GraphiQL IDE
-- Block ACF fields cannot be queried in the GraphiQL IDE

package/docs_old/docs/serverless/1.overview.md

@@ -1 +0,0 @@
-# Overview

package/docs_old/docs/serverless/2.config.md

@@ -1 +0,0 @@
-# Config

package/docs_old/docs/serverless/3.wordpress-vercel.md

@@ -1,8 +0,0 @@
-# WordPress + Vercel
-
-WIP
-
-- `SITE_URL` environment variable in Vercel
-- `serverless.endpoints` option in `ed.config.json` — so that:
-  - Frontend code executed in WordPress can access API endpoints hosted on Vercel
-  - WordPress can redirect to the Vercel URL if WordPress is being used completely headless

package/docs_old/docs/serverless/4.apis.md

@@ -1 +0,0 @@
-# APIs

package/docs_old/docs/serverless/5.rpc.md

@@ -1 +0,0 @@
-# RPC API

package/docs_old/docs/serverless/_category_.json

@@ -1,4 +0,0 @@
-{
-  "label": "☀️ Serverless",
-  "position": 5
-}

package/docs_old/docs/stack/1-WordPress.md

@@ -1,18 +0,0 @@
----
-sidebar_position: 1
----
-
-# WordPress
-
-There are several CMS' out there, and while WordPress may not be the most modern, it's very well known (both to clients and developers) and is easy to work with and host.
-
-## Why not a cloud-based headless CMS + Next.js?
-
-We use WordPress as a semi-headless CMS. While there are plenty of cloud-based headless CMS' out there, there are several issues with using them:
-
-- They can be quite expensive!
-- They often lack features we require, such as versioning, translation, ecommerce, user registration, user-submitted data, live preview and block-based content editing. These features are also often hidden behind an expensive 'Enterprise' plan.
-- The lack of specific features often leads to the requirement of additional third-party platforms, which adds a great deal of complexity to our projects.
-- Integrating them with frameworks like Next.js require lots of boilerplate code, which becomes hard to maintain.
-- Next.js' file-based routing is great for web apps, but imposes limitations on URL customisation which are hard to overcome.
-- We love our elegant page transitions, and these are harder to achive with Next.js.

package/docs_old/docs/stack/2-Flywheel.md

@@ -1,15 +0,0 @@
----
-sidebar_position: 2
----
-
-# Flywheel + Local
-
-Our primary WordPress hosting provider is [Flywheel](https://getflywheel.com/). We have an organisation plan which allows us to host hundreds of WordPress sites, managed in an easy-to-use [dashboard](https://app.getflywheel.com/).
-
-[Local](https://localwp.com/) is a desktop app which provides a development environment for WordPress sites, and was developed by Flywheel. It has useful 'sync' functionality, allowing you to push/pull files and the database between Local and a Flywheel site.
-
-## Local Sync
-
-Feel free to use Local Sync to deploy your WordPress site to Flywheel during the initial stages of development, however it's recommended that you use Github Actions to automate code deployment.
-
-Pulling from Flywheel to Local is also a great way to pull down a site to work on it locally — just don't forget to re-clone the theme folder so that it's correctly linked to Git.

package/docs_old/docs/stack/3-React.md

@@ -1,12 +0,0 @@
----
-sidebar_position: 3
----
-
-# React
-
-There's not much to say! React is great. It's particularly great for complex UI.
-
-Be sure you're across React, hooks and how to use TypeScript with React. You should also probably know how Context works
-
-- [React Hooks Guide on Smashing Magazine](https://www.smashingmagazine.com/2020/04/react-hooks-api-guide/) — goes over all the core hooks, as well as how to create custom hooks.
-- [React & TypeScript: how to type hooks (a complete guide)](https://devtrium.com/posts/react-typescript-how-to-type-hooks) — learn by looking! Lots of examples and tips on how to correctly use hooks with TypeScript.

package/docs_old/docs/stack/4-TypeScript.md

@@ -1,13 +0,0 @@
----
-sidebar_position: 4
----
-
-# TypeScript
-
-TypeScript is a typed superset of JavaScript that compiles to plain JavaScript. We use TypeScript to write code that is easier to read and understand, although it is not as fast as JavaScript.
-
-Some resources:
-
-- [TypeScript — The Basics](https://www.youtube.com/watch?v=ahCwqrYpIuM) (video)
-- [TypeScript with React](https://www.notion.so/ed-studio/ED-Stack-2021-Tour-7f50bc455d95403ebdff9a4503a78aee#b15ee6c11d40449e8f18b9ff19301901) (Udemy course)
-- [React & TypeScript: how to type hooks (a complete guide)](https://devtrium.com/posts/react-typescript-how-to-type-hooks) — learn by looking! Lots of examples and tips on how to correctly use hooks with TypeScript.

package/docs_old/docs/stack/5-WPGraphQL.md

@@ -1,21 +0,0 @@
-# (WP)GraphQL
-
-"GraphQL is a query language for APIs and a runtime for fulfilling those queries with your existing data. GraphQL provides a complete and understandable description of the data in your API, gives clients the power to ask for exactly what they need and nothing more, makes it easier to evolve APIs over time, and enables powerful developer tools." (from the [GraphQL Website](https://graphql.org/)).
-
-The [WPGraphQL](https://www.wpgraphql.com/) plugin (which is actually installed in the theme with Composer, rather than a plugin), provides a GraphQL API for WordPress.
-
-## Schemas
-
-GraphQL requires a server to be running to serve the queries. The WPGraphQL plugin provides a server that can be accessed at the URL `/graphql`, or via the `graphql()` PHP function.
-
-The schema is automatically generated for you by the plugin, and makes all WordPress data available to you via queries.
-
-You can define your own types and fields on the schema using the PHP functions documented on the [WPGraphQL website](https://www.wpgraphql.com/functions/).
-
-## Queries
-
-Queries are written in `.graphql` files, which can be stored in three locations in your code.
-
-- `blocks/*/*.graphql`, alongside a block's `.tsx` file. Queries in these files will be run automatically by the server when the page is visited, and the data is passed as props to the block component. This allows blocks to query any other data on the site. Blocks can also query ACF fields defined on the block, via the global `block` field, which represents the current block being executed.
-- `views/*.graphql`, alongside any View `.tsx` file. Just like blocks, the data is passed to the view's component. They can also use special variables to refer to the current post, or some querystring value.
-- `queries/*.graphql`— these queries will have React hooks automatically generated for them, allowing the queries or mutations to be executed on demand by your React code. This is useful for components which need to perform searching/filtering/pagination, handle user data submissions, trigger server-side code etc.

package/docs_old/docs/stack/6-eddev.md

@@ -1,9 +0,0 @@
-# `eddev` Library
-
-## Purpose
-
-TBA
-
-## Features
-
-TBA

package/docs_old/docs/stack/_category_.json

@@ -1,4 +0,0 @@
-{
-  "label": "📚 The Stack",
-  "position": 1
-}

package/docs_old/docs/tooling/1.scripts.md

@@ -1,25 +0,0 @@
-# Scripts
-
-## `yarn dev`
-
-The 'dev' command provides hot-reloading for multiple bundles — like frontend, admin and (eventually) serverless.
-
-It's custom built, and made to be as clean as possible by showing issues relevant to the most recent attempt at a rebuild.
-
-### Webpack
-
-Internally, the system uses [Webpack](https://webpack.js.org/) and [webpack-dev-server](https://webpack.js.org/configuration/dev-server/), along with [react-refresh](https://github.com/pmmmwh/react-refresh-webpack-plugin). Webpack configuration is _not editable_, and is auto-generated by the tool itself. We may swap Webpack out for another tool such as `swc` or `esbuild` at some point in the future for an additional speed boost, and so allowing access to Webpack config could result in compatibility issues.
-
-For speed, each Webpack bundle runs in a separate worker thread, so that each bundle can compile concurrently, taking advantage of multiple CPU cores.
-
-### GraphQL Codegen
-
-The dev tool also provides realtime GraphQL -> TypeScript generation, by monitoring your project for changes and rebuilding when appropriate. For this, we're using [GraphQL Code Generator](https://www.graphql-code-generator.com/) with a host of custom plugins.
-
-These files are _only_ generated by the dev tool, and not be the `yarn build` tooling. This only really matters for dynamic queries in the `queries/` folder. To be safe, you should always make sure `yarn dev` runs after editing a `.graphql` file in your project.
-
-## `yarn build`
-
-This produces production builds of the frontend and admin bundles, with tree shaking, minification and code-splitting.
-
-It also produces a bundle sizing report, in `/dist/frontnend/bundle-report.html` — which you can use to see which dependencies are bloating up your bundle files. If a dependency is too large, consider dynamically importing it instead.

package/docs_old/docs/tooling/2.aliases.md

@@ -1,13 +0,0 @@
-# Aliases
-
-There are a few import aliases predefined for you.
-
-```
-@components/* -> ./components/*
-@hooks/*      -> ./hooks/*
-@utils/*      -> ./utils/*
-@theme        -> ./theme.css.tsx
-@queries      -> ./hooks/queries.ts
-```
-
-This just means that you can use absolute paths to import your components and hooks etc, rather than having to use relative paths — making copy/pasting of import statements around your codebase a little bit easier.

package/docs_old/docs/tooling/3.defines.md

@@ -1,13 +0,0 @@
-# Defines
-
-There are a few globally accessible variables which you can access, which are defined via Webpack's `DefinePlugin`
-
-From [Webpack configuration docs](https://webpack.js.org/plugins/define-plugin/):
-
-> The `DefinePlugin` replaces variables in your code with other values or expressions at compile time. This can be useful for allowing different behavior between development builds and production builds. If you perform logging in your development build but not in the production build you might use a global constant to determine whether logging takes place. That's where DefinePlugin shines, set it and forget it rules for development and production builds.
-
-The following variables are available:
-
-- `process.dev` — `true` or `false`, depending on whether this bundle is targetting at dev mode or not.
-- `process.admin` - `true` or `false`, depending on whether this bundle is used for the admin editor (Gutenberg) or on the frontend. Useful for rendering blocks for better editing experience.
-- `process.themePath` - The relative URI pointing to the theme directory. Useful for calculating the location of assets. Note that there is NO trailing slash.

package/docs_old/docs/tooling/4.config-file.md

@@ -1,14 +0,0 @@
-# Config File
-
-You'll find a `ed.config.json` file in the root of your theme folder. This file is read by both the `eddev` dev and build tool, along with the supporting `eddev-php` library.
-
-Here are the options:
-
-- `serverless` — An optional object.
-  - `enabled` — `true` or `false` — Controls whether serverless node is enabled for this project.
-  - `uploads` — `"proxy"` or `"remote"`
-  - `plugins` — `"proxy"` or `"remote"`
-  - `theme` — `"proxy"`, `"remote"` or `"copy"`
-  - `devAssets` — an optional array of glob paths or file names, relative to the theme folder, which are necessary for the frontend — this includes `assets/**` by default.
-
-You can also find the original schema file [here](https://github.com/ed-digital/eddev/blob/main/src/config/config-schema.ts).