npm package discovery and stats viewer.

Discover Tips

  • General search

    [free text search, go nuts!]

  • Package details

    pkg:[package-name]

  • User packages

    @[username]

Sponsor

Optimize Toolset

I’ve always been into building performant and accessible sites, but lately I’ve been taking it extremely seriously. So much so that I’ve been building a tool to help me optimize and monitor the sites that I build to make sure that I’m making an attempt to offer the best experience to those who visit them. If you’re into performant, accessible and SEO friendly sites, you might like it too! You can check it out at Optimize Toolset.

About

Hi, 👋, I’m Ryan Hefner  and I built this site for me, and you! The goal of this site was to provide an easy way for me to check the stats on my npm packages, both for prioritizing issues and updates, and to give me a little kick in the pants to keep up on stuff.

As I was building it, I realized that I was actually using the tool to build the tool, and figured I might as well put this out there and hopefully others will find it to be a fast and useful way to search and browse npm packages as I have.

If you’re interested in other things I’m working on, follow me on Twitter or check out the open source projects I’ve been publishing on GitHub.

I am also working on a Twitter bot for this site to tweet the most popular, newest, random packages from npm. Please follow that account now and it will start sending out packages soon–ish.

Open Software & Tools

This site wouldn’t be possible without the immense generosity and tireless efforts from the people who make contributions to the world and share their work via open source initiatives. Thank you 🙏

© 2024 – Pkg Stats / Ryan Hefner

quasar-app-extension-sowell-auth-beta

v0.0.1

Published

A Quasar auth app extension

Downloads

3

Readme

Quasar App Extension plugin.auth

Add a short description of your App Extension. What does it do? How is it beneficial? Why would someone want to use it?

npm npm

Install

quasar ext add mamy-auth

Quasar CLI will retrieve it from NPM and install the extension.

Prompts

When installing the Auth app extension, you will be prompted with fourteen questions:

  1. Route for authentication

The default is /login, it allows you to define the login route

  1. Route where the user will be redirected once connected

The default is /, you can define where you want to be redirect once connected

  1. Route for code verification after performing the forgotten password

The default is /check_code, you can define other route

  1. Route for password update

The default is /reset_password

  1. Basic server route

The default is http://localhost:3000, you must point it to your server base url

  1. Server route for authentication

The default is /users/sign_in

  1. Server route to reset password

The default is /users/reset_password

  1. Server route to update password

The default is /users/passwords

  1. Authorization type

The default is Bearer but you can change it according to your needs

  1. Vuex mutation to set token

The default is auth/setToken in the auth module. It can be changed from the moment it takes the token in parameter

  1. Vuex mutation to clear token and all user state

The default is auth/clearToken in the auth module but can be changed

  1. Vuex mutation to set user information when resetting password (email or phone number)

The default is auth/setInfosUser in auth module. It takes email or phone number, can be changed

  1. Vuex getter to return token

The default is auth/getToken and return token, can be changed.

  1. Vuex getter to return user information

The default is auth/getInfosUser and return email or phone number

Uninstall

quasar ext remove mamy-auth

Info

The parent application must provide the following mutations:

A mutation to store the token, it takes the token in parameter

A mutation to clean the token and the user information

A mutation to define the user information during the process of forgotten password (email or phone number), it takes in parameter the email or the phone number.

A getter which returns the token

A getter that returns the email or the phone number defined during the process of forgotten password.

When installing the extension, the path to these mutations and getters must be provided. As well as the different routes of the pages and APIs, without forgetting the type of authorization.

Usage

In auth mutation:

export function setToken(state, payload) {
    state.token = payload
}

export function clearToken(state) {
    state.token = null
}

In auth getter:

export function getToken(state) {
    return state.token
}

Parent Application (UI)

A Quasar Framework app for Auth Extension

Install the dependencies

yarn dep

Start the app in development mode (hot-code reloading, error reporting, etc.)

yarn dev

Lint the files

yarn lint

Launch test with Cypress Studio

yarn test:e2e

Launch test with Cypress mode CI (Continuous Integration )

yarn test:e2e:ci

Customize the configuration

See dev/Configuring quasar.conf.js.

Info

Cypress automatically after being launched.

Usage

For Cypress Studio

Launch test E2E mode and select your test file

For Cypress Continuous Integration mode

Launch test E2E with Continuous integration mode and cypress test all file in directory:

    /test/cypress/integration/

netlify-plugin-cypress

CircleCI [![renovate-app badge][renovate-badge]][renovate-app] netlify-plugin-cypress Netlify Status

Runs Cypress end-to-end tests on Netlify Build

Install and use

You can install this plugin in the Netlify UI from this direct in-app installation link or from the Plugins directory.

For file based installation, add netlify-plugin-cypress NPM package as a dev dependency to your repository.

npm install --save-dev netlify-plugin-cypress
# or
yarn add -D netlify-plugin-cypress

And then add the plugin's name to the list of build plugins in netlify.toml file as shown in the examples below.

note: this plugin assumes you have already installed Cypress as a dev NPM dependency.

How does it work

Build steps

When Netlify Build system runs it performs 2 steps essentially:

  1. builds the site
  2. deploys the site

Every plugin that wants to perform some actions can do so before the build, after the build (but before the deploy), and after the deploy. The Netlify uses the following names for these events

"preBuild"
1. builds the site
"postBuild"
2. deploys the site
"onSuccess"
"onFailure"

Thus every plugin can register itself to be executed before a site is built using "preBuild" event, or after a successful deploy using "onSuccess" event name, etc.

This plugin

This plugin netlify-plugin-cypress by default runs during the "onSuccess" event, testing the deployed site. The Netlify Build system gives the URL to the plugin and it runs Cypress against that URL using the Cypress NPM module API.

Optionally, you can also run tests during "preBuild" and "postBuild" steps. This is useful if you want to ensure the site is working even before deploying it to Netlify servers. Finally, this plugin does not use "onFailure" event which happens only if Netlify fails to deploy the site.

Failing the deploy

Running Cypress tests by default uses the "onSuccess" step of the build pipeline. By this point Netlify has already deployed the site. Even if the tests fail now, the Netlify shows the successful deployment - the site is live! To really prevent the broken deploys, we suggest using Cypress GitHub / GitLab / Bitbucket integration to fail the status checks on a pull request.

We also suggest running tests during the "preBuild" and/or "postBuild" steps. If the tests fail during these steps, the Netlify fails the entire build and does not deploy the broken site.

Finally, you can set up Slack notifications on failed tests against the deployed site. At least you will quickly find out if the deployed site fails the E2E tests and would be able to roll back the deploy.

Examples

basic

Here is the most basic Netlify config file netlify.toml with just the Cypress plugin

[[plugins]]
  # runs Cypress tests against the deployed URL
  package = "netlify-plugin-cypress"

tutorial

Read the full tutorial at Test Sites Deployed To Netlify Using netlify-plugin-cypress.

Note: if any tests against the deployed URL fail, the Netlify build still considers it a success. Thus if you want to have a test check against the deploy, install Cypress GitHub App. The app will provide its own failing status check in this case.

options

You can control the browser, the specs to run, record tests on Cypress Dashboard, etc, see manifest.yml file.

recording

To record test results and artifacts on Cypress Dashboard, set record: true plugin input and set CYPRESS_RECORD_KEY as an environment variable via Netlify Deploy settings.

[build]
command = "npm run build"
publish = "build"
  [build.environment]
  # cache Cypress binary in local "node_modules" folder
  # so Netlify caches it
  CYPRESS_CACHE_FOLDER = "./node_modules/CypressBinary"
  # set TERM variable for terminal output
  TERM = "xterm"
[[plugins]]
# runs Cypress tests against the deployed URL
package = "netlify-plugin-cypress"
  [plugins.inputs]
  record = true

See cypress-example-kitchensink and recorded results at Cypress Dashboard netlify-plugin-cypress

Security note 🔐: you should keep your CYPRESS_RECORD_KEY secret. You can control how Netlify builds external pull requests, see the doc - you never want to expose sensitive environment variables to outside builds.

status checks

If you are recording test results to Cypress Dashboard, you should also install Cypress GitHub Integration App to see status checks from individual groups or from individual specs per commit. See netlify-plugin-prebuild-example PR #8 pull request for an example.

Netlify to Cypress Dashboard to GH Integration checks

group

You can change the group name for the recorded run using group parameter

[[plugins]]
# runs Cypress tests against the deployed URL
package = "netlify-plugin-cypress"
  [plugins.inputs]
  record = true
  group = "built site"

tag

You can give recorded run tags using a comma-separated string. If the tag is not specified, Netlify context will be used (production, deploy-preview or branch-deploy)

[[plugins]]
# runs Cypress tests against the deployed URL
package = "netlify-plugin-cypress"
  [plugins.inputs]
  record = true
  group = "built site"
  tag = "nightly,production"

spec

Run only a single spec or specs matching a wildcard

[build]
command = "npm run build"
publish = "build"
  [build.environment]
  # cache Cypress binary in local "node_modules" folder
  # so Netlify caches it
  CYPRESS_CACHE_FOLDER = "./node_modules/CypressBinary"
  # set TERM variable for terminal output
  TERM = "xterm"
[[plugins]]
# runs Cypress tests against the deployed URL
package = "netlify-plugin-cypress"
  [plugins.inputs]
  spec = "cypress/integration/smoke*.js"

See cypress-example-kitchensink for instance.

browser

By default all tests run using the Chromium browser. If you want to use Electron:

[build]
command = "npm run build"
publish = "build"
  [build.environment]
  # cache Cypress binary in local "node_modules" folder
  # so Netlify caches it
  CYPRESS_CACHE_FOLDER = "./node_modules/CypressBinary"
  # set TERM variable for terminal output
  TERM = "xterm"
[[plugins]]
package = "netlify-plugin-cypress"
  [plugins.inputs]
  # allowed values: electron, chromium
  browser = "electron"

configFile

If you would like to use a different Cypress config file instead of cypress.json, specify it using the configFile option

[build]
command = "npm run build"
publish = "build"
  [build.environment]
  # cache Cypress binary in local "node_modules" folder
  # so Netlify caches it
  CYPRESS_CACHE_FOLDER = "./node_modules/CypressBinary"
  # set TERM variable for terminal output
  TERM = "xterm"
[[plugins]]
package = "netlify-plugin-cypress"
  [plugins.inputs]
  configFile = "cypress.netlify.json"

testing SPA routes

SPAs need catch-all redirect setup to make non-root paths accessible by tests. You can enable this with spa parameter.

[[plugins]]
# local Cypress plugin will test our site after it is built
package = "netlify-plugin-cypress"
  [plugins.inputs]
  # can also use "spa = true" to use "index.html" by default
  spa = "index.html"

testing the site before build

By default this plugin tests static site after deploy. But maybe you want to run end-to-end tests against the local development server. You can start the local server, wait for it to respond and then run Cypress tests by passing parameters to this plugin. Here is a sample config file

[[plugins]]
  package = "netlify-plugin-cypress"
  # let's run tests against development server
  # before building it (and testing the built site)
  [plugins.inputs.preBuild]
    enable = true
    start = 'npm start'
    wait-on = 'http://localhost:5000'
    wait-on-timeout = '30' # seconds

Parameters you can place into preBuild inputs: start, wait-on, wait-on-timeout, spec, record, group, and tag.

See netlify-plugin-prebuild-example repo

testing the site after build

By default this plugin tests static site after deploy. But maybe you want to run end-to-end tests locally after building the static site. Cypress includes a local static server for this case but you can specify your own command if needed by using the start argument. Here is a sample config file

[[plugins]]
  package = "netlify-plugin-cypress"
  # let's run tests against the built site
  [plugins.inputs.postBuild]
    enable = true

Parameters you can place into postBuild inputs: spec, record, group, tag, start and spa.

The SPA parameter

If your site requires all unknown URLs to redirect back to the index page, use the spa parameter

[[plugins]]
  package = "netlify-plugin-cypress"
  # let's run tests against the built site
  [plugins.inputs.postBuild]
    enable = true
    # must allow our test server to redirect unknown routes to "/"
    # so that client-side routing can correctly route them
    # can be set to true or "index.html" (or similar fallback filename in the built folder)
    spa = true
    start = 'npm start'

using Netlify CLI

Even better when testing the prebuilt site is to run the Netlify CLI to make sure the local API redirects and Netlify functions work in addition to the web site. Add netlify-cli as a dev dependency and start it during testing.

$ npm i -D netlify-cli
[[plugins]]
  package = "netlify-plugin-cypress"
  # start Netlify server
  [plugins.inputs.preBuild]
    start = 'npx netlify dev'
    wait-on = 'http://localhost:8888'

For more, see tests/test-netlify-dev example and read Testing Netlify Function section.

skipping tests

If you are testing the site before building it and want to skip testing the deployed URL

[[plugins]]
  package = "netlify-plugin-cypress"
  # do not test the deployed URL
  [plugins.inputs]
    enable = false
  # test the local site
  [plugins.inputs.preBuild]
    enable = true

parallelization

Running tests in parallel is not supported because Netlify plugin system runs on a single machine. Thus you can record the tests on Cypress Dashboard, but not run tests in parallel. If Netlify expands its build offering by allowing multiple build machines, we could take advantage of it and run tests in parallel.

HTML files

When serving the built folder, we automatically serve .html files. For example, if your folder has the following structure:

public/
  index.html
  pages/
    about.html

The public folder is served automatically and the following test successfully visits both the root and the about.html pages:

cy.visit('/')
cy.visit('/pages/about') // visits the about.html

Warning: be careful with verbose logging, since it can print all environment variables passed to the plugin, including tokens, API keys, and other secrets.

Donate

If you appreciate the work that went into this App Extension, make donation to Sowell

License

MIT (c) Sowell