Giter VIP home page Giter VIP logo

v6-docs's Introduction

Docs boilerplate

The boilerplate repo we use across AdonisJS projects to create a documentation website. The boilerplate allows for maximum customization without getting verbose.

Why not use something like VitePress?

I have never been a big fan of a frontend first tooling when rendering markdown files to static HTML. I still remember the Gridsome and Gatsby days, when it was considered normal to use GraphQL to build a static website ๐Ÿ˜‡.

With that said, the feature set around rendering markdown feels modern and refreshing with frontend tooling. But, the underlying libraries are not limited to the frontend ecosystem, and you can use them within any JavaScript project.

So, if I have all the tools at my disposal, why not build and use something simple that does not change with the new wave of innovation in the frontend ecosystem?

Workflow

The docs boilerplate is built around the following workflow requirements.

  • Create a highly customizable markdown rendering pipeline. I need control over rendering every markdown element and tweaking its HTML output per my requirements. This is powered by @dimerapp/markdown and @dimerapp/edge packages.

  • Use Shiki for styling codeblocks. Shiki uses VSCode themes and grammar for syntax highlighting and requires zero frontend code.

  • Use a base HTML and CSS theme to avoid re-building documentation websites from scratch every time. But still allow customizations to add personality to each website.

  • Use a dumb JSON file to render the docs sidebar (JSON database file). Scanning files & folders and sorting them by some convention makes refactoring a lot harder.

  • Allow linking to markdown files and auto-resolve their URLs when rendering to HTML.

  • Allow keeping images and videos next to markdown content and auto-resolve their URLs when rendering to HTML.

Folder structure

.
โ”œโ”€โ”€ assets
โ”‚  โ”œโ”€โ”€ app.css
โ”‚  โ””โ”€โ”€ app.js
โ”œโ”€โ”€ bin
โ”‚  โ”œโ”€โ”€ build.ts
โ”‚  โ””โ”€โ”€ serve.ts
โ”œโ”€โ”€ content
โ”‚  โ”œโ”€โ”€ docs
โ”‚  โ””โ”€โ”€ config.json
โ”œโ”€โ”€ src
โ”‚  โ”œโ”€โ”€ bootstrap.ts
โ”‚  โ””โ”€โ”€ collections.ts
โ”œโ”€โ”€ templates
โ”‚  โ”œโ”€โ”€ elements
โ”‚  โ”œโ”€โ”€ layouts
โ”‚  โ”œโ”€โ”€ partials
โ”‚  โ””โ”€โ”€ docs.edge
โ”œโ”€โ”€ vscode_grammars
โ”‚  โ”œโ”€โ”€ dotenv.tmLanguage.json
โ”‚  โ””โ”€โ”€ main.ts
โ”œโ”€โ”€ package-lock.json
โ”œโ”€โ”€ package.json
โ”œโ”€โ”€ README.md
โ”œโ”€โ”€ tsconfig.json
โ””โ”€โ”€ vite.config.js

The assets directory

The assets directory has the CSS and frontend JavaScript entry point files. Mainly, we import additional packages and the base theme inside these files. However, feel free to tweak these files to create a more personalized website.

The bin directory

The bin directory has two script files to start the development server and export the docs to static HTML files. These scripts boot the AdonisJS framework under the hood.

The content directory

The content directory contains the markdown and database JSON files. We organize markdown files into collections, each with its database file.

You can think of collections as different documentation areas on the website. For example: You can create a collection for docs, a collection for API reference, and a collection for config reference.

See also: Creating new collections

The src directory

The src directory has a bootstrap file to wire everything together. We do not hide the bootstrap process inside some packages. This is because we want the final projects to have complete control over configuring, pulling in extra packages, or removing unused features.

The collections.ts file is used to define one or more collections.

The templates directory

The templates directory contains the Edge templates used for rendering HTML.

  • The docs template renders a conventional documentation layout with the header, sidebar, content, and table of contents. You may use the same template across multiple collections.
  • The logos are kept as SVG inside the partials/logo.edge and partials/logo_mobile.edge files.
  • The base HTML fragment is part of the layouts/main.edge file. Feel free to add custom meta tags or scripts/fonts inside this file.

The vscode_grammars directory

The vscode_grammars directory contains a collection of custom VSCode languages you want to use inside your project.

See also: Using custom VSCode grammars

Usage

Clone the repo from GitHub. We recommend using degit, which downloads the repo without git history.

npx degit dimerapp/docs-boilerplate <my-website>

Install dependencies

cd <my-website>
npm i

Run the development server.

npm run dev

And visit http://localhost:3333/docs/introduction URL to view the website in the browser.

Adding content

By default, we create a docs collection with an introduction.md file inside it.

As a first step, you should open the content/docs/db.json file and add all the entries for your documentation. Defining entries by hand may feel tedious at first, but it will allow easier customization in the future.

A typical database entry has the following properties.

{
  "permalink": "introduction",
  "title": "Introduction",
  "contentPath": "./introduction.md",
  "category": "Guides"
}
  • permalink: The unique URL for the doc. The collection prefix will be applied to the permalink automatically. See the src/collection.ts file for the collection prefix.
  • title: The title to display in the sidebar.
  • contentPath: A relative path to the markdown file.
  • category: The grouping category for the doc.

Once you have defined all the entries, create markdown files and write some real content.

Changing website config

We use a very minimal configuration file to update certain website sections. The config is stored inside the content/config.json file.

{
  "links": {
    "home": {
      "title": "Your project name",
      "href": "/"
    },
    "github": {
      "title": "Your project on GitHub",
      "href": "https://github.com/dimerapp"
    }
  },
  "fileEditBaseUrl": "https://github.com/dimerapp/docs-boilerplate/blob/develop",
  "copyright": "Your project legal name"
}
  • links: The object has two fixed links. The homepage and the GitHub project URL.

  • fileEditBaseUrl: The base URL for the file on GitHub. This is used inside the content footer to display the Edit on GitHub link.

  • copyright: The name of display in the Copyright footer.

  • menu: Optionally, you can define a header menu as an array of objects.

    {
      "menu": [
        {
          "href": "/docs/introduction",
          "title": "Docs",
        },
        {
          "href": "https://blog.project.com",
          "title": "Blog",
        },
        {
          "href": "https://github.com/project/releases",
          "title": "Releases",
        }
      ]
    }
  • search: Optionally, you can define config for the Algolia search.

    {
      "search": {
        "appId": "",
        "indexName": "",
        "apiKey": ""
      }
    }

Creating new collections

You may create multiple collections by defining them inside the src/collections.ts file.

A collection is defined using the Collection class. The class accepts the URL to the database file. Also, call collection.boot once you have configured the collection.

// Docs
const docs = new Collection()
  .db(new URL('../content/docs/db.json', import.meta.url))
  .useRenderer(renderer)
  .urlPrefix('/docs')

await docs.boot()

// API reference
const apiReference = new Collection()
  .db(new URL('../content/api_reference/db.json', import.meta.url))
  .useRenderer(renderer)
  .urlPrefix('/api')

await apiReference.boot()

export const collections = [docs, apiReference]

Using custom VSCode grammar

You may add custom VSCode languages support by defining them inside the vscode_grammars/main.ts file. Each entry must adhere to the ILanguageRegistration interface from Shiki.

Changing the markdown code blocks theme

The code blocks theme is defined using the Markdown renderer instance created inside the src/bootstrap.ts file. You can either use one of the pre-defined themes or a custom theme.

export const renderer = new Renderer(view, pipeline)
  .codeBlocksTheme('material-theme-palenight')

Customizing CSS

The base docs theme makes extensive use of CSS variables, therefore you can tweak most of the styling by defining a new set of variables.

If you want to change colors, we recommend looking at Radix Colors, because this is what we have used for the default styling.

Customizing HTML

The HTML output is not 100% customizable since we are not creating a generic docs generator for the rest of the world. The boilerplate is meant to be used under constraints.

However, you can still control the layout, because all sections of the page are exported as Edge component and you can place them anywhere in the DOM. Do check the templates/docs.edge file to see how everything is used.

Header slots

You may pass the following component slots to the website header.

  • logo (required): Content for the logo to display on Desktop viewport.

  • logoMobile (required): Content for the logo to display on Mobile viewport.

  • popupMenu (optional): Define custom markup for the popup menu trigger. The trigger is displayed in mobile view only.

    @component('docs::header', contentConfig)
      @slots('popMenu')
        <span> Open popup menu </span>
      @end
    @end
  • themeSwitcher (optional): Define custom markup for the theme switcher button.

    @component('docs::header', contentConfig)
      @slots('themeSwitcher')
        <span x-if="store.darkMode.enabled"> Dark </span>
        <span x-if="!store.darkMode.enabled"> Light </span>
      @end
    @end
  • github (optional): Define custom markup for the github link in the header.

    @component('docs::header', contentConfig)
      @slots('github')
        <span> GitHub (11K+ Stars) </span>
      @end
    @end

v6-docs's People

Contributors

abdullahcanakci avatar aikrom avatar amir-mohammad-hp avatar e-e avatar edikurniawan-dev avatar emmadedayo avatar fabnguess avatar g3offrey avatar johann-s avatar julien-r44 avatar max98 avatar maximemrf avatar melchyore avatar memsbdm avatar mle-moni avatar nekoding avatar nhedger avatar powdotkim avatar raesta avatar romainlanz avatar rtivital avatar shaheedazaad avatar shahriarkh avatar shankiflang avatar sooluh avatar stancobridge avatar thetutlage avatar vimalgorasiya avatar vspinellis avatar ziut3k-dev avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar

v6-docs's Issues

Possible typo in documentation - `ref` instead of `rel`

Package version

N/A

Describe the bug

Congratulations on the v6 release!

I believe I found a potential typo in the documentation. In the Referencing assets inside Edge templates section, there's an example showing how a user can link directly to a Vite compiled stylesheet. The example shows a ref attribute on a <link> tag.

I can't find any references to a ref attribute for the <link> element in the usual documentation or the HTML specifications. Is it possible that the documentation should be updated to rel?

If so: happy to spin up a PR and get it fixed.

References

Reproduction repo

Not applicable

New docs is hard to read and understand

Package version

no

Describe the bug

would love to help you shaping documentation ๐Ÿ’›

Hello,

First, thanks and congratulation for the v6. ๐Ÿ™Œ

But, even if the framework looks very well, the documentation is hard to read. Let me explain it.

Full width for a website could have a nice look but for a documentation, I do not think it's a good idea. Here how it looks on my computer:

image

I have to go from right, the TOC, to the left, the nav, it's tiring.

Then, I do not understand the nav.

The getting started section is not a getting started section. At that point, I do not really care of config or env vars or even FAQs. I'm testing the frameworks to see if it fit my needs.

Why is HTTP so huge? You say in the /guides/http that this layer is composed from router, controllers, HttpContext, Middelware, Global Exception handler and Server. There are the part I expect from this section.

Why Views and Template loose it's section? It's important for a web framework to render a view! It's now in the HTTP section but there nothing about it in the introduction of the section.

Why fundamentals come from after mail? The IoC container, the service provider and more are things that make Adonis different (and better) that any other JS frameworks. And despite that the section is called "Fundamentals", it's at the end of the nav.

Scaffolding, Tooling, Async Local Storage and TypeScript build process are important, yes, but clearly not a fundamentals for a beginner.

Extending the framework is cool but clearly advanced usage. Not needed in the fundamentals section.

Digging Deeper looks like a "everything you don't know where to put". Internationalization is important, same for authorization but it's put under a no name section.

Ace command line is at the end, after the commad-line tests? I'm testing an ace command line but I still do not know what an ace command line is.

Many parts of AdonisJS have been extracted with their own website like Japa, Edge, Vine, Lucid. That's nice but it's complicated to find them, so many click from the AdonisJS docs to the correct website. I expect a big button to easily understand that I can learn more on a dedicated website. Views page seems limited with not a lot of content but it's only because everything have move to the website of Edge.

Suggestions

  • Introduction but cover more specificity of the framework (IoC, all-in-one, modular, extensible)
  • Create an architecture section which explain, in-depth, how the framework works, IoC, services, extensibility, packages....)
  • HTTP is not a great name (actually) because we expect a WS section or even a TCP one. Name it Concepts or Basics and put under it only the necessary to understand, globally, Adonis. Nothing specific like File uploads, validation, URL builder, views, static file server...
  • Social authentication must be put under the auth section
  • Authorization could be put under auth or security
  • I18n could have it's own section
  • Saffolding, Tooling, ... are pages for degging deeper section
  • You could create a Guides section with file uploads, validation, assets bundling, logger, emitter
  • Ace command line could be renamed Command Line since you do not have any other name in title (no Japa, Edge and more) and the section could come before others. REPL could be in the Basis section.
  • Add a menu with all related packages (Japa, Vine, Edge)...
  • Linked pages to their package using links under the toc
  • Having a "edit this page" link under the toc

There is many things we could do but I think it's a great overview on how you could improve the documentation.

Reproduction repo

No response

New structure proposal

Hey there! ๐Ÿ‘‹๐Ÿป

As discussed internally with the core team, I want to revamp how the documentation is structured.

I mainly took example on an internal proposal I made for AdonisJS 3 documentation, current AdonisJS 4 and 5 documentation and Laravel documentation.

The end goal is to have something simple for newcomers to go through, and even for recurring users without loosing any content.
I believe we split a bit too much some information across many pages, so I merged a few sections together (like we had in AdonisJS 5 documentation)

A complete structure can be found at the end of this message.

On a side note, this structure has been made during a live stream in front of ~100 people. They also gave feedback and thought to build this new structure.

This proposal will go through each section, point by point, explaining its content and its goal.

Legend:

  • (From: *) - If the name has been changed, this will contain the old name OR it help to distinguish the content if we have the same name multiple time
  • (+ *) - We are merging content
  • (New) - New content we have to write
  • (~New) - New content we have to gather from other pages
  • (PR) - New content with a PR
  • (Previously: *) - Proposal for a rename
  • (?) - Not sure if needed here

Preface
โ”œโ”€โ”€ Introduction (From: Getting Started - Introduction)
โ”œโ”€โ”€ FAQ
โ”œโ”€โ”€ Governance
โ”œโ”€โ”€ Release Notes
โ””โ”€โ”€ Contribution Guide

This section is ordered in a logical way.

The goal of this section is to provide all "meta" information about the framework. Its philosophy, faq, governance status, etc.


Getting Started
โ”œโ”€โ”€ Installation (From: Getting Started - Installation)
โ”œโ”€โ”€ Configuration
โ”œโ”€โ”€ Environment Variables
โ”œโ”€โ”€ Folder Structure
โ””โ”€โ”€ Deployment (From: AdonisJS 4 - Deployment)

This section is ordered in a logical way.

The goal of this section is to have a Zero to Production information for a minimum setup. I believe all sub-sections are needed to have a minimum understanding of all the defaults boilerplate.


AdonisJS Concepts
โ”œโ”€โ”€ Application
โ”œโ”€โ”€ Application Lifecycle
โ”œโ”€โ”€ Config Providers
โ”œโ”€โ”€ RC Files
โ”œโ”€โ”€ Service Container
โ””โ”€โ”€ Scaffolding

This section is ordered by alphabetical order.

The goal of this section is to explain concepts linked to AdonisJS and how we structured our and the application code.


Architecture Concepts
โ”œโ”€โ”€ Async Local Storage
โ”œโ”€โ”€ Dependency Injection (Previously: IoC Container )
โ”œโ”€โ”€ HMR (PR)
โ”œโ”€โ”€ Http Context
โ”œโ”€โ”€ Request Lifecycle (From: HTTP - Introduction)
โ””โ”€โ”€ Service Providers

This section is ordered by alphabetical order.

The goal of this section is to explain common architectural concepts we may found in other frameworks.


Basics
โ”œโ”€โ”€ Routing (+ URL Building)
โ”œโ”€โ”€ Controllers
โ”œโ”€โ”€ Middleware
โ”œโ”€โ”€ Requests (+ BodyParser middleware)
โ”œโ”€โ”€ Response
โ”œโ”€โ”€ Validation
โ”œโ”€โ”€ File Upload
โ”œโ”€โ”€ Session
โ”œโ”€โ”€ Cookies
โ”œโ”€โ”€ Exception Handling
โ””โ”€โ”€ Static Assets (Assets bundling + Static server)

This section is ordered in a logical way.

The goal of this section is to contain anything relative for building simple project. Nearly all of those features are needed for a standard SSR application.


Database
โ”œโ”€โ”€ Introduction (~New - From: SQL and ORMs)
โ”œโ”€โ”€ Lucid ORM (~New - From: SQL and ORMs)
โ””โ”€โ”€ Redis

This section is ordered in a logical way.

The goal of this section is to contain anything related to database you may want to use with AdonisJS. In the feature, we may add Kysely or Prisma there for example.


Authentication
โ”œโ”€โ”€ Introduction (From: Authentication - Introduction)
โ”œโ”€โ”€ User Providers (+ Verifying user credentials)
โ”œโ”€โ”€ Auth Guards (+ all the guards doc)
โ””โ”€โ”€ Social Authentication

This section is ordered in a logical way.

Another proposal for this section would be to keep all the auth guard separated:

โ”œโ”€โ”€ Session Guard
โ”œโ”€โ”€ Access Token Guard
โ”œโ”€โ”€ Basic Auth Guard
โ”œโ”€โ”€ Custom Auth Guard

The goal of this section is to contain anything related to authentication.


Security
โ”œโ”€โ”€ Introduction (New)
โ”œโ”€โ”€ Authorization
โ”œโ”€โ”€ Encryption
โ”œโ”€โ”€ Hashing
โ”œโ”€โ”€ Signed URLs (?)
โ”œโ”€โ”€ Web Security (+ CORS + Securing SSR apps)
โ””โ”€โ”€ Rate Limiting

This section is ordered in a logical way.

The goal of this section is to contain anything related to securing an application.


Views & Templates
โ”œโ”€โ”€ Introduction (~New - From:  HTTP - Views and Templates)
โ”œโ”€โ”€ EdgeJS (~New - From:  HTTP - Views and Templates)
โ””โ”€โ”€ InertiaJS (From: Experimental - InertiaJS)

This section is ordered in a logical way.

The goal of this section is to contain anything related to views and templates. We may add TSX or KitaJS in the future in this section.


Testing
โ”œโ”€โ”€ Introduction
โ”œโ”€โ”€ Http Tests
โ”œโ”€โ”€ Browser Tests
โ”œโ”€โ”€ Console Tests
โ”œโ”€โ”€ Database
โ””โ”€โ”€ Mocks & Fakes

This section is ordered in a logical way.

The goal of this section is to contain anything related to testing. No real change from what we have right now.


Digging Deeper
โ”œโ”€โ”€ Ace Commands (+merge all doc)
โ”œโ”€โ”€ Caching (New)
โ”œโ”€โ”€ Emitter
โ”œโ”€โ”€ I18n
โ”œโ”€โ”€ Locks
โ”œโ”€โ”€ Logger
โ”œโ”€โ”€ Mail (+merge all doc)
โ”œโ”€โ”€ Transmit (PR)
โ””โ”€โ”€ Extending the framework

This section is ordered by alphabetical order except the last point.

The goal of this section is to contain anything that is less used than the Basic section to make an application. The goal is keep one page per feature.

Also, Ace Commands will probably move to its own website.


API References
โ””โ”€โ”€ NO CHANGE

No change for this section.


Internals
โ”œโ”€โ”€ Tooling Config
โ””โ”€โ”€ TypeScript Build

This section is ordered by alphabetical order.

The goal of this section is to contain anything not directly related to people's application. Internal process.


Experimentals
โ””โ”€โ”€ NO CHANGE

No change for this section.


FINAL SIDEBAR

Preface
โ”œโ”€โ”€ Introduction
โ”œโ”€โ”€ FAQ
โ”œโ”€โ”€ Governance
โ”œโ”€โ”€ Release Notes
โ””โ”€โ”€ Contribution Guide

Getting Started
โ”œโ”€โ”€ Installation
โ”œโ”€โ”€ Configuration
โ”œโ”€โ”€ Environment Variables
โ”œโ”€โ”€ Folder Structure
โ””โ”€โ”€ Deployment

AdonisJS Concepts
โ”œโ”€โ”€ Application
โ”œโ”€โ”€ Application Lifecycle
โ”œโ”€โ”€ Config Providers
โ”œโ”€โ”€ RC Files
โ”œโ”€โ”€ Service Container
โ””โ”€โ”€ Scaffolding

Architecture Concepts
โ”œโ”€โ”€ Async Local Storage
โ”œโ”€โ”€ Dependency Injection
โ”œโ”€โ”€ HMR
โ”œโ”€โ”€ Http Context
โ”œโ”€โ”€ Request Lifecycle
โ””โ”€โ”€ Service Providers

Basics
โ”œโ”€โ”€ Routing
โ”œโ”€โ”€ Controllers
โ”œโ”€โ”€ Middleware
โ”œโ”€โ”€ Requests
โ”œโ”€โ”€ Response
โ”œโ”€โ”€ Validation
โ”œโ”€โ”€ File Upload
โ”œโ”€โ”€ Session
โ”œโ”€โ”€ Cookies
โ”œโ”€โ”€ Exception Handling
โ””โ”€โ”€ Static Assets

Database
โ”œโ”€โ”€ Introduction
โ”œโ”€โ”€ Lucid ORM
โ””โ”€โ”€ Redis

Authentication
โ”œโ”€โ”€ Introduction
โ”œโ”€โ”€ User Providers
โ”œโ”€โ”€ Auth Guards
โ””โ”€โ”€ Social Authentication

Security
โ”œโ”€โ”€ Introduction
โ”œโ”€โ”€ Authorization
โ”œโ”€โ”€ Encryption
โ”œโ”€โ”€ Hashing
โ”œโ”€โ”€ Signed URLs
โ”œโ”€โ”€ Web Security
โ””โ”€โ”€ Rate Limiting

Views & Templates
โ”œโ”€โ”€ Introduction
โ”œโ”€โ”€ EdgeJS
โ””โ”€โ”€ InertiaJS

Testing
โ”œโ”€โ”€ Introduction
โ”œโ”€โ”€ Http Tests
โ”œโ”€โ”€ Browser Tests
โ”œโ”€โ”€ Console Tests
โ”œโ”€โ”€ Database
โ””โ”€โ”€ Mocks & Fakes

Digging Deeper
โ”œโ”€โ”€ Ace Commands
โ”œโ”€โ”€ Caching
โ”œโ”€โ”€ Emitter
โ”œโ”€โ”€ I18n
โ”œโ”€โ”€ Locks
โ”œโ”€โ”€ Logger
โ”œโ”€โ”€ Mail
โ”œโ”€โ”€ Transmit
โ””โ”€โ”€ Extending the framework

API References
โ””โ”€โ”€ NO CHANGE

Internals
โ”œโ”€โ”€ Tooling Config
โ””โ”€โ”€ TypeScript Build

Experimentals
โ””โ”€โ”€ NO CHANGE

Full file examples

Hi,

The problem I have with the documentation, and it is by no means unique to Adonis but rather the norm, is the lack of full file examples. Like, with service providers, there are all these snippets of doing a binding, or a register, but nothing to show us what an entire provider file looks like. A link or a screenshot at the bottom with "Tying It All Together" would be very helpful.

i18n Not working AdonisJS 6

Creating app by mode API
...
1 - npm i @adonisjs/i18n

2 - node ace configure @adonisjs/i18n

3 - file config:
import app from '@adonisjs/core/services/app'
import { defineConfig, formatters, loaders } from '@adonisjs/i18n'

const i18nConfig = defineConfig({
defaultLocale: 'pt-br', // nothing works, fr, es... etc
formatter: formatters.icu(),
supportedLocales: ['pt-br'],
loaders: [
/**
* The fs loader will read translations from the
* "resources/lang" directory.
*
* Each subdirectory represents a locale. For example:
* - "resources/lang/en"
* - "resources/lang/fr"
* - "resources/lang/it"
*/
loaders.fs({
location: app.languageFilesPath(),
}),
],
})

export default i18nConfig


4 - As of VineJS, no changes have been made; everything remains in English, and the 'resources' directory is not present or does not exist.

Does this only work with Edge? cant change DateTime luxor too, all returning iso in dbquery and all.

Health Check

Package version

0.0.0

Describe the bug

I see there is a healthCheck field in database config but there is no mention in the docs of this.

Reproduction repo

No response

Reference to Packages

Package version

0.0.0

Describe the bug

Is there any reference to the v6 packages site in the v6 documentation? https://packages.adonisjs.com/

I would expect a page explaining the spirit behind packages, those that are formally supported, and something about community packages for example.

While I didn't check every single page I don't see anything in the sidebar about packages. Algolia search doesn't bring up anything useful.

I took a look at the v5 documentation and while there isn't a dedicated page there is a link the in Resources dropdown at the top of the page.

If I was new to Adonis I probably wouldn't be aware of the package ecosystem after going through the documentation.

Just a thought.

Reproduction repo

No response

Weird phrasing in `Views and Templates`

Package version

n/a

Describe the bug

The following phrasing in Views and Templates is a bit weird.

Optionally, you can opt for libraries like HTMX or Unpoly to progressively enhance your application navigate like an SPA.

I may PR something later, but I thought I'd report anyway, just in case I forgot.

Reproduction repo

No response

Feature request - Prev/Next page links

Helloooo, I just started a few minutes ago to read the doc on my mobile phone and I think it can be really good for ux if we can have a "prev/next" links section at the bottom of a doc page.

I don't know if it's planned and possible, I don't know if I can contribute, i will dig it soon !

Example: https://docusaurus.io/docs

issues on auth session guard v6 doc

Package version

@adonisjs/[email protected]

Describe the bug

Hello,

Today we started a new project with adonis 6, and I'm facing some errors in documentation about authentication setup.
We used the web template, so I ran node ace configure @adonisjs/auth as asked in https://v6-alpha.adonisjs.com/docs/auth/introduction#installation

Then follow the session guard guide https://v6-alpha.adonisjs.com/docs/auth/session_guard

  • Configuration seems to be outdated because providers do not exists in @adonisjs/auth
  • I tried to implement Remember me feature but tokenProviders is not exported from @adonisjs/auth/session. So I gave up for this feature (not mandatory)
  • I followed the How to login section and attempt do not exists in auth.use('web'). after some search in source code, I guessed the new method is
const user = await User.verifyCredentials(email, password)
await auth.use('web').login(user)

Best regards

Reproduction repo

No response

Lucid documentation bad link from search engine

Package version

v6-docs

Describe the bug

Hello guys, nice work on v6 !

How to reproduce:
Search on Google by example "doc Adonisjs lucid"

When I click on the page named Introduction with the url : "https://docs.adonisjs.com/guides/database/sql"
I get a "ERR_TOO_MANY_REDIRECTS"

If it is a url from old pages of the v5 documentation maybe return a 301 with the new location will be a good fix.

Thanks

Reproduction repo

No response

Installation error with yarn

Hey,

I have already talked about this privately with @Julien-R44, so here is the issue I encountered while following the documentation.

During installation via the command yarn create adonisjs@latest hello-world, I encountered an error.

image

This error is because the keyword latest does not exist since Yarn by default takes the latest version.

You can specify a version, of course, but not use this keyword.

PR to fix the "problem" : #74

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.