Description

Consolidate and remove .gitignore files under packages where possible.
Also, let's switch to setting includes in the package.json files property, vs setting excludes via .npmignore files.

Package(s): @gasket/*

AC:

• Cleaned up repo-level .gitignore file
• No unneeded .gitignore files under packages/*
• Remove all .npmignore files
• Update packages' package.json with files property

And investigate a good approach to define or expose the prompt function types interface.

Description

Currently, the @gasket/plugin-intl allows configuring a supported locales array, for the purpose of passing along to Next.js for i18n routing of static pages. A suitable requested feature is to also use this for other non-Next static pages. In the @gasket/helper-intl, we should fallback back to the defaultLocale when supported locales are specified and the requested locale is not included.

Package(s): @gasket/helper-intl

AC:

• When supported locales is configured, but requested locale is not included, load path for defaultLocale.

Description

There may be some cases where refs are need for components wrapped with the HOCs, as such these refs should be forward by the HOCs.

NOTE: While addhoc forwards refs, and was investigated for these HOCs, it does not allow for the wrapping code access to the components own properties, necessary for these.

Package(s): @gasket/react-intl

AC:

• Refs automatically forwarded by HOCs

Description

There have been asks to use gasket create or an equivalent command for scaffolding non-app packages.

Package(s): @gasket/

AC:

• Ability to create a package (non-app) using the Gasket CLI with plugins

If one runs the following:

npm i -g @gasket/cli
gasket create myapp -p @gasket/preset-nextjs
cd myapp
npx gasket build
DEBUG=express* npx gasket local

We quickly see the express debug output:

  express:application set "x-powered-by" to true +0ms
  express:application set "etag" to 'weak' +1ms
  express:application set "etag fn" to [Function: generateETag] +0ms
  express:application set "env" to 'development' +1ms
  express:application set "query parser" to 'extended' +0ms
  express:application set "query parser fn" to [Function: parseExtendedQueryString] +0ms
  express:application set "subdomain offset" to 2 +0ms
  express:application set "trust proxy" to false +0ms
  express:application set "trust proxy fn" to [Function: trustNone] +1ms
  express:application booting in development mode +0ms
  express:application set "view" to [Function: View] +0ms
  express:application set "views" to './myapp/views' +0ms
  express:application set "jsonp callback name" to 'callback' +0ms
  express:router use '/' query +0ms
  express:router:layer new '/' +0ms
  express:router use '/' expressInit +1ms
  express:router:layer new '/' +0ms
  express:router use '/' cookieParser +0ms
  express:router:layer new '/' +0ms
  express:router use '/' compression +0ms
  express:router:layer new '/' +0ms
  express:router use '/' middleware +5ms
  express:router:layer new '/' +1ms
  express:application set "buildId" to 'A-9cIUPb32ud1LBi1mROp' +40ms
  express:router:route new '*' +2ms
  express:router:layer new '*' +0ms
  // ...
  // ... etc
  // ...

Today we do a good job of documenting the possible graph of Hooks, and Lifecycles that will be executed for a given Command:

However, when we consider the plugin & preset authoring experience it's not as much about understanding the entire graph of possibilities but mapping out and debugging a single walk of that graph for a given gasket app process. This can be challenging today and a full understanding of the order of operations is often based on intuition, not hard data.

I propose we add similar debug output to @gasket/engine so that when one runs:

DEBUG=gasket* npx gasket start

They would get the walk of the graph of all hooks when starting at gasket/plugin-start above and moving from left to right in the traversal order that happens at runtime.

Description

In the CLI and some of our plugins we are looking up and loading .js files. We need to expand this list to also include newer .mjs and .cjs files. ESM will support will require (pun not intended) a larger separate refactor to use import statements.

Package(s): @gasket/cli, @gasket/plugin-lifecycle, @gasket/plugin-lint, *

AC:

• Identify where special files are looked up
• Ability to load special files with varying extensions in a gasket app

Description

Rename @gasket/intl to @gasket/react-intl in order to clarify the intended purpose of this package and to differentiate from future locale loader packages for frameworks other than React.

Package(s): @gasket/intl, @gasket/plugin-intl

AC:

• Updated package name
• Updated references in docs and code
• Update plugin to only add @gasket/react-intl of React is also being installed code comment

Description

We use promisify for several things that now already have promise support. Let's do a code cleanup pass for these.

• fs -> fs.promises
• [email protected] -> mkdirp@^1.x

AC:

• Do not use promisify with fs (use fs.promises)
• Align mkdirp dependency across packages
• Check for updates to other packages and avoid promisify where possible

We need to drop Enzyme from our scaffolded tests. Enzyme has not been kept up for React 17 and the recommended library is now React Testing Library.

Packages: @gasket/plugin-mocha, @gasket/plugin-jest

AC:

• Scaffold Mocha tests using React Testing Library
• Scaffold Jest tests using React Testing Library

Description

We need to add support for HTTP/2 in Gasket apps. Ideally, this can just be a
configuration property in the gasket.config.js. Alternatively, if required
then a new http2 plugin.

Package(s): @gasket/plugin-https?, create-servers?

AC:

• Ability to serve Gasket apps over HTTP/2

Description

Review our existing code and write up tickets for todos and deprecation that would be valuable to get in for the next major release.

AC:

• Tickets outlining work required for next major Gasket release

Description

Move away from window.gasketData and use the new @gasket/data package.

Package(s): @gasket/react-intl

AC:

• Ability to read gasketData.intl from @gasket/data

🐛 Bug Report

The out of date marked dependency is in gasket-plugin-docsify which depends on [email protected]. This version is the latest available today. The module is actively worked on, so lets update to 5.x as soon as its available.

➜  gasket-plugin-docsify git:(master) ✗ npm ls marked
@gasket/[email protected] /path/to/gasket/packages/gasket-plugin-docsify
└─┬ [email protected]
  └── [email protected]

Description

We should have opt-in support for serving static locale files with server layer (express, fastify)? It maybe we helpful for existing apps to migrate to using the public dir with NextJS.

This option could be called serveStatic. If it is true in the config, set the endpoint to the defaultPath. We might also want allow the option to be set to a string and use that as the static endpoint. (i.e. serveStatic: '/locales'). This would be helpful if an app's default locale happens to differ from the static path.

Package(s): @gasket/plugin-intl

AC:

• Ability to configure Gasket apps with endpoint for serving static locale files
• Ability for existing apps to migrate to v6 without moving locale files

Description

In order to fully support static site creation, we need to allow service workers to be generated to a file at build-time. Retaining support for request-time generating should continue to be supported.

package(s): @gasket/plugin-server-worker, @gasket/plugin-workbox

AC:

• Ability to create static service worker file
• Ability to compose workbox with static sw
• Retain support for requested sw

Description

Links to docs for create-gasket-app are missing from the Gasket docs index.
This is because there is no metadata set for the package.

Package(s): @gasket/*

AC:

• Ability to link to create-gasket-app docs from generated index.

Description

Currently, some lifecycles in the graph docs do not accurately show when they
are executed. We need to allow for non-commands to be displayed as root events.
There will likely be a pass required on some metadata for plugins accordingly.

Package(s): @gasket/*

AC:

• Lifecycle graph able to show custom root events (i.e. Requests)

Description

Currently, we use LocaleRequired in our component, HOC, and hook to load translated/localized files. The current name can yield a bit of confusion, since you are not loading a locale, but rather a localized message file. Technically, locale is required, which determines which version of the translated file to load, but the purpose of the components is to specify which translated file.

So, instead of withLocaleRequired, should we change these to be withTranslation, or withLocalizedFile, or withLocaleMessages?

Package(s): @gasket/react-intl

AC:

• Vet this question with current users and document
• Proposal for next steps if any.

Description

As a bit of cleanup, and incase teams/apps ever want to use it, we should rename the useGasketIntl React hook to follow our component names as useLocaleRequired and export it from the package. The locale statuses should also be static properties that apps and compare the hook results against.

Package(s): @gasket/react-intl

AC:

• Ability for apps to utilize useLocaleRequired

Description

Just as we show tables of the available lifecycles, commands, and such for a gasket app in the index generated from gasket docs, let's also include a table describing the available config options.

AC:

• Ability to describe config in metadata, for automating docs
• Add config section to generated index by docs command

🐛 Bug Report

running npx gasket local fails to run http/https servers. This is due to it attempting to run on port 80 which is a privileged port.

To Reproduce

npm i -g @gasket/cli
gasket create *app-name* --presets @gasket/nextjs
npx gasket local

Expected Behavior

expects to work out of the box on a basic setup/install with out needing to modify http/https

Environment

Manjaro Linux (Arch based OS) local environment

Description

The vast majority of times that lifecycles are hooked, it is for app-level one-offs. Let's do a pass on our doc examples to demonstrate this format, rather than in plugin hooks.

There may be some lifecycle examples where plugin are the suitable example to show, so use discretion in these changes.

Package(s): @gasket/*

AC:

• Lifecycle examples demonstrate {{lifecycles/}} files over plugin hooks.

Description

We need a way for app config to be made available in the browser, when Redux is not used. Today, teams can set config under a Redux property which will make it available in the Redux store.

For this change, we should introduce a new special property (public) which will add its values to res.locals.gasketData.config, and thus be made available in the browser under with @gasket/data as gasketData.config.

Package(s): @gasket/plugin-config

AC:

• Ability to set public data with config plugin
• Ability to access public data in browser with @gasket/data

Description

We should go ahead and drop next-routes support. It is buggy with built-in routing, and it was removed from our docs already in #215.

Package(s): @gasket/plugin-nextjs
Version: major v6

AC:

• Automatic routes.js file detection and loading removed
• Update any additional docs for clarification

Description

After an early investigation with built-in i18n routing from Next, our Gasket Intl package is pretty close to just work with it. Our solution for supporting GSSP and GSP is similar, so let's tune things up for it.

Package(s): @gasket/intl, @gasket/plugin-intl
Branch: canary

AC:

• Ability to use Gasket Intl locale determination with Next.js routing
  • Next issue and/or contribution?
• Update GSP and GSSPs to work with Next.js locales
• Ability to specify supported locales (locales) in Gasket config
  • Gasket locale determination should use this, also...
  • intl.locales and intl.defaultLocale should be pass to nextConfig.

Description

The gasket.logger can be useful to add logging to requests and middleware but currently requires developers to do extra work to make it available to these areas of their apps. We should provide a common way to access the configured Gasket Logger by attaching it to res.locals.gasketLogger automatically by @gasket/plugin-log.

Package(s): @gasket/plugin-log

AC:

• Ability to access the gasket logger in for request in route and middleware code.

Description

The smart method of webpack-merge has been deprecated. We should move away from it in the webpack plugin. Reference the webpack-merge docs and changelog for details and suggested alternatives.

Package(s): @gasket/plugin-webpack

AC:

• No longer merging webpack configs with deprecated method
• Merge results should match our existing output

Stretch:

• Ability for apps to customize webpack merge routine

Description

We need a streamlined approach for locales to be preloaded to the response in order to be accessible by the server for endpoints or document rendering. This could be something like req.withLocaleRequire('/locales') with a selector method to pick a message key such as req.selectLocaleMessage('hello')

Also, this data should be normalized with LocalesProps as in in the Next.js loaders in @gasket/react-intl
See this code comment

Package(s): @gasket/plugin-intl

AC:

• Ability to load locales paths for server response
• Ability to select a translation for use on server
• Loaded locales uses same structure as @gasket/react-intl/nextjs loaders

Description

Based on our latest testing, it seems like getInitialProps is more suitable for server-side rendering to load locale files than GSSP is. GSSP is called for client-routing too, which is unnecessary since locale files should only be fetched once. Let's bring back getInitialProps as an option, possibly again as part of the HOC.

Package(s): @gasket/intl
Branch: canary

AC:

• Ability to use getInitialProps using the withLocaleRequired

We should avoid using the first and last timing properties with our Gasket plugins. These can cause timing confusion with custom plugins for end users. Because this would more than likely result in a breaking change with timings, this should be handled in our next major version.

Description

We need to allow plugins to add files/directories to the .gitignore to generate the file cleanly and flexible.

Package(s): @gasket/

AC:

• Ability for plugins to add to what's generated in the .gitignore file

Description

Package(s): @gasket/*

AC:

• Packages using latest dependencies and devDependencies
• All dependency version aligned and properly hoisted

Description

We need to removing name convention fallback code to avoid unwanted tech debt.

Package(s): @gasket/resolve, @gasket/engine, @gasket/cli

AC:

• Remove tech debt code around naming convention fallback
• Remove deprecation warnings
• App should hard-fail if configured plugin is not found (no fallback)

Problem Statement

TypeScript enthusiasts like me want as much of our code to be written in TypeScript as possible. As a user of @gasket/preset-nextjs, I enjoy the fact that the next.js integration gives me the ability to author some of my code in TypeScript (React components for example), but it's frustrating that any code compatible with SSR (/store.js) or pure gasket artifacts /lifecycles cannot be authored in TypeScript without some hackery or degradation in developer experience (DX).

Technical Challenges

There are many technical challenges to supporting TypeScript source code in gasket applications:

• Gasket, being a framework engine, needs to remain as tiny as possible and mandate as few technology choices as possible. This includes TypeScript. We therefore would prefer not to have Gasket automatically support TypeScript out of the box.
• Developers find the presence of compilation artifacts residing alongside their source code to be a nuisance and a potential source of bugs if these artifacts are not up-to-date. Though they may be receptive to having to compile prior to a deployment, they do not wish to have to dodge extraneous file artifacts in their workspace or rely on starting a watching builder to keep things current.
• However, node-loadable source files are a must for packages like @gasket/plugin-lifecycles, which lists the files in a /lifecycles directory and dynamically loads that code, and @gasket/plugin-redux which needs to discover a redux store factory.

Another tangential thing that developers may desire is the ability to automatically restart gasket servers when code changes. This avoids those confusing moments where you're tearing your hair out wondering why the code is not behaving as written because you forgot to restart.

Current Workarounds

Although TypeScript outside of next.js-built components is not officially supported, some approaches have been employed to support it within some projects, falling into two broad categories. Here are the challenges with these workarounds:

Building TypeScript files before running gasket

Running tsc before invoking the gasket CLI causes generated .js files to be placed alongside .ts files so that they're discoverable by Gasket. This works, but:

• It is annoying to developers who now have to navigate both .js and .ts files in their source files.
• For next.js apps, care has to be taken to make sure the TypeScript compilation doesn't conflict with the built-in TS support used when generating webpack artifacts. The ideal compiled output for a browser versus node differs, so you end up wanting different configurations for those two targets.
• If you'd like your Gasket server to be restarted on source files changes, you have to take care that only code for the server side does this since next.js already has hot module reloading for client-side artifacts, and you wouldn't want changes to React component .tsx files to provoke server restarts.

Registering a module loader for TypeScript files

Another workaround involves registering a module loader for .ts files, using techniques like @babel/register or ts-node/register early in the source code of a gasket app, such as in gasket.config.js. This has some challenges:

• It requires heavy toolchains like babel or typescript to be deployed alongside an app's dependencies since they are now used at runtime instead of just build time.
• Although it addresses issues with importing source code, every package, that dynamically loads source code, such as @gasket/plugin-lifecycle, needs to know to look for other file extensions like .ts.
• Source changes to server code not provoking restarts is also not addressed.

Proposed Solution

• Add a gasket config property like extensions that is an array of which file extensions gasket plugins should look for when dynamically loading source files (or can we read this from Module?). This should have a reasonable default for typical node development.
• Update plugins that do code discovery, like @gasket/plugin-lifecycle, to use this extensions config value.
• In @gasket/plugin-start or a new @gasket/plugin-clean plugin:
  • Introduce a new clean command to gasket
  • Inject a clean package.json script that invokes gasket clean
• Add clean hooks for any plugin that generates build artifacts, like @godaddy/gasket-plugin-intl
• Create a @gasket/plugin-nodemon package which:
  • Hooks the create lifecycle and generates:
    • A devDependency on nodemon
    • A nodemon.json with useful defaults
    • A modified local package.json script which invokes gasket local via nodemon
  • Emits a nodemonConfig lifecycle event during create to enable plugins to modify the generated config
• Create a @gasket/plugin-typescript package, which:
  • Hooks the configure lifecycle, injecting .ts (and maybe .tsx?) as an extension.
  • Hooks the create lifecycle after @gasket/plugin-nodemon and generates:
    • Appropriate devDependencies, like:
      • typescript
      • ts-node
      • @types/foo dependencies for any packages with known external type definitions. These will be read by invoking a new tsTypeDefinitionPackages lifecycle, enabling any plugin to register their own type definitions.
    • Two TypeScript config files, one for client code (tsconfig.json so it's picked up by the next.js babel compiler), one for server code
    • Appropriate .gitignore modifications
    • A modified local package.json script where ts-node is used to execute gasket or nodemon --exec ts-node if it's already wrapped by nodemon.
  • Hooks the nodemonConfig lifecycle and adds watching of .ts files, except those that are likely to be client-only
  • Hooks the build lifecycle, invoking tsc with the server config file if the gasket command isn't local
  • Hooks the clean lifecycle, deleting generated .js files

Description

Package(s): @gasket/cli

AC:

• Ability to configure extra extensions for special files
• Ability to load special files with custom extensions
  • Specifically, support for add TypeScript extension (.ts)
  • Also provide TS setup docs with example for configuring in gasket.config.js

Problem

A common issue we encounter with Gasket apps has to do with controlling which middlewares run when. For example, an app with mixed API and UI routes may receive undesired calls to Hydra for API-based requests, or requests for static resources may unexpectedly incur calls to Hivemind. The tools our developers have for avoiding these are rudimentary; we have a single RegExp which can be used to skip all plugin-injected middlewares for some URL patterns, but there's no granularity beyond that.

Proposal

Designate a known set of middleware stacks

If we have the ability to classify requests and assign middlewares only to certain categories, this would give us more control over which middlewares run for which requests. For example, we would only want to run the UXP middlewares for UI routes, the Auth middlewares for UI and API routes but neither of them for proxied requests. We could call these categories "stacks." Our first step would be to identify a set of stacks that would indicate which types of processing will be required to fulfill the request. A given request may be assigned multiple stacks. This list of possibilities may look something like this:

• authorized
• ui
• api
• asset
• proxy

Add a stacks lifecycle

The https plugin could now inject a handler in front of the handling provided by @gasket/plugin-express or @gasket/plugin-fastify. This handler would invoke gasket.execWaterfall('stacks', new Set(), { req, res }); Anything hooking stacks could add to or remove from that Set of strings. Once stacks finishes running, the resulting Set would identify which middlewares should be applied. This could now be attached to the request or response objects, like maybe res.locals.stacks.

Allow setting stacks in config

Although end-users could create their own lifecycle hook for stacks to customize default behaviors we could consider also allowing customization via gasket.config.js.

Enable middleware injectors to specify stacks

Inside of the middleware lifecycle we could now allow each returned middleware to be tagged with the stacks that it should be applied to.

One way this could work is to allow a [Middleware, string[]] tuple to be used in any place where a middleware function is allowed, where that array of strings indicates the applicable stacks. An empty Array would be a special case indicating that it applies to all requests, and for the sake of backwards compatibility anything not specifying stacks would also be applied to all requests. Tuples would be compact but may not be intuitively obvious in meaning, so another option is to allow an object, which would also open us up for future extensibility, something like { handler: MiddlewareFn, stacks: string[] }

Plugins implementing the middleware like @gasket/plugin-express could now wrap middlewares indicating stacks in a higher-order middleware to suppress them if a set of stacks is not present:

function runForStacks(stacks: Array<string>, handler: Handler): Handler {
  return (req, res, next) =>
    !res.locals.stacks?.size || stacks.some(category => res.locals.stacks.has(category))
      ? handler(req, res, next)
      : next();
  }
}

Description

Overall guide for apps using v5 to reference in order to get to the v6 version of plugins.

Package(s): @gasket/docs

AC:

• Docs detailing changes required to upgrade an app from v5 to v6

Description

We need to expose an allPlugins getter method from create context for listing all plugins including those from presets. This will be useful for condition checks during the prompt and create lifecycles.

We do a check like this here, but we should expose a simpler helper which lifecycle hooks can also utilize.

Package(s): @gasket/cli

AC:

• Ability to check if a plugin has been added for installation during prompt or create lifecycles.

Description

In order to allow plugins to add flags to commands, we need a new getCommandFlags lifecycle.
Plugins can use this command to add custom flags that they want to listen for. By default
new flags will be added for all commands. The getCommandFlags lifecycle should allow plugins to also limit
which commands should be effected.

As a first custom, we should update @gasket/plugin-metrics to use the new lifecycle to add the record flag
and drop it (from the command plugin).

Package(s): @gasket/plugin-command

AC:

• Ability for plugins to add custom flags to commands
• Ability to limit which commands receive flags
• Update @gasket/plugin-metrics to add record flag

There are a few ways to shave this yak – this proposal is just one:

1. Create @gasket/preset-https in packages/gasket-preset-https with plugins:
   • @gasket/plugin-config
   • @gasket/plugin-docs
   • @gasket/plugin-docsify
   • @gasket/plugin-express
   • @gasket/plugin-https
   • @gasket/plugin-lint
   • @gasket/plugin-log
2. Update @gasket/preset-nextjs to depend on this preset.
3. Update Structures at https://gasket.dev to make clear that several files in the structure are for specific presets / plugins.
   • Add a structure just for @gasket/preset-https – perhaps tabs or pills to switch?

Description

We should be creating new apps against Webpack 5. Also, tune any of our existing plugins (namely, UXP plugin) to work with this as well in their next major version branch.

Package(s): @gasket/plugin-webpack, @godaddy/gasket-plugin-uxp

AC:

• New apps created with Webpack 5 installed
  • Verify apps created with @gasket/plugin-nextjs work with Webpack 5
• Update existing plugins' webpack config lifecycle hooks

Description

For some teams, it is preferable to store app app code under a /src directory.
Currently, special directories need to be at the root of the repo. We should tune
this up to also allowing placing these under the /src.

Package(s): @gasket/cli, @gasket/plugin-lifecycle, *

AC:

• Identify where special files are looked up
• Ability to place special files under /src directory

Description

Next 10 has been released. We should make it the default for new Gasket apps under v6, and make sure our packages are updated to support it.

https://nextjs.org/blog/next-10

Package(s): @gasket/plugin-nextjs, @gasket/react-intl

AC:

• New v6 Gasket apps are created with next@10
• Ability to use @gasket/react-intl with next@10

Description

There is a lot of inline documentation in the Gasket CLI code, specifically for on create context, that should be more easily readable. Let's render these jsdocs to markdown as we do in other packages.

Package(s): @gasket/cli

AC:

• Ability to read API markdown docs for the create command and its context.

Description

In order to fully support static site creation, we need to allow the web manifest to be generated to a file at build-time. Retaining support for request-time generating should continue to be supported.

package(s): @gasket/plugin-manifest

AC

• Ability to create static web manifest .json file
• Retain support for requested web manifest

This issue lists Renovate updates and detected dependencies. Read the Dependency Dashboard docs to learn more.

Rate-Limited

These updates are currently rate-limited. Click on a checkbox below to force their creation now.

• fix(deps): update docusaurus monorepo to v2.4.1 (@docusaurus/core, @docusaurus/preset-classic)
• chore(deps): update dependency @svgr/core to v8
• chore(deps): update dependency eslint-plugin-unicorn to v47
• chore(deps): update dependency global-jsdom to v9
• chore(deps): update dependency jsdom to v22
• chore(deps): update dependency nx to v16
• fix(deps): update dependency workbox-build to v6
• 🔐 Create all rate-limited PRs at once 🔐

Edited/Blocked

These updates have been manually edited so Renovate will no longer make changes. To discard all commits and start over, click on a checkbox.

• chore(deps): update dependency webpack to 5.76.0 [security]

Open

These updates have all been created already. Click a checkbox below to force a retry/rebase of any.

• chore(deps): replace dependency babel-eslint with @babel/eslint-parser ^7.11.0
• chore(deps): update dependency @testing-library/react to v14
• chore(deps): update dependency start-server-and-test to v2
• fix(deps): update dependency node-fetch to v3
• fix(deps): update dependency ora to v6
• fix(deps): update dependency rimraf to v5
• fix(deps): update dependency swagger-jsdoc to v6
• fix(deps): update dependency url-join to v5
• fix(deps): update dependency webpack-merge to v5
• Click on this checkbox to rebase all open PRs at once

Ignored or Blocked

These are blocked by an existing closed PR and will not be recreated unless you click a checkbox below.

• chore(deps): update dependency whatwg-fetch to v3.6.2
• chore(deps): update dependency fastify to v4
• chore(deps): update dependency jsdoc-to-markdown to v8
• chore(deps): update dependency sinon to v15
• chore(deps): update dependency typescript to v5
• chore(deps): update nextjs monorepo to v13 (major) (eslint-config-next, next)
• fix(deps): update dependency @fastify/swagger to v8
• fix(deps): update dependency @oclif/core to v2
• fix(deps): update dependency @types/lru-cache to v7
• fix(deps): update dependency escape-string-regexp to v5
• fix(deps): update dependency fs-extra to v11
• fix(deps): update dependency glob to v10
• fix(deps): update dependency inquirer to v9
• fix(deps): update dependency lru-cache to v9
• fix(deps): update dependency markdown-table to v3
• fix(deps): update dependency middie to v7
• fix(deps): update dependency mkdirp to v3

Detected dependencies

• Check this box to trigger a request for Renovate to run again on this repository

We should do an iteration on the Preset authoring guide and add some guidance for testing during development, such as a using the hidden --preset-path flag with the create command.