drashland / deno-drash-middleware Goto Github PK

Summary

When using ServeTypeScript to import multiple typescript files, the generated file (in-memory), contains only one typescript file, and the original file content selected in config doesn't appear in the memory. Example, if you have 4 files: main.ts, a.ts, b.ts, c.ts, and main.ts import all 3 files, only one of them will appear in browser, and the main.ts content is missing in the memory file.

Steps To Reproduce The Bug

1. Write the config choosing the realPathSync of main.ts file

import { ServeTypeScript } from "../deps.ts";
const serveCompiledTs = ServeTypeScript({
  files: [
    {
      source: Deno.realPathSync("./frontsystem/main.ts"), // the path to the actual TypeScript file
      target: "/ts/frontsystem.min.ts", 
    },
  ],
});

2. Write main.ts to import 4 other files

//main.ts
import { A } from "./models/A.ts";
import { B } from "./util/B.ts";
import { C } from "./views/C.ts";
import { D } from "./views/D.ts";
const B = new B();
console.log("I'm working");
//models/A.ts
class A {
    public name: string;
    constructor(){
        this.name = 'name';
    }
}
//same to other files

3. Run the server.
4. Verify the file at the browser.

Expected Behavior

All files imported together

Suggested Solution(s)

Still learning, sorry

Additional Context

Files used in the original problem has more than 300 lines each

Summary

What: HTTP responses should send the ETag response header for improved caching. See https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/ETag for more info.

Why: Improve caching.

Acceptance Criteria

• The ETag should be present in response headers.
• @Lonniebiz points out a potential performance issue. Testing/benchmarking must be included for this feature. See his comment below for more information.

Example Pseudo Code (for implementation)

response.headers.set("ETag", getHeader_eTag());

Summary

What: Allow user to specify if the token should be stored in a header or cookie

Why: Storing in cookies is less hassle and easier to work with, allow less maintenance or code to manage it

Acceptance Criteria

• Add cookie?: boolean into the configs. Default to false

Summary

What: Add tornado middleware, using https://github.com/stormpath/express-stormpath/blob/master/OLD-README.md as inspriration

Description from Express' website: "User storage, authentication, authorization, SSO, and data security."

It doesn't have to be named tornado, but it's similar to the original middleware and unique, plus it sounds freaking awesome right!?

Why: Tornado as a middleware sounds cool! And it will add utility for users... i guess there's that

Acceptance Criteria

• develop middleware
• Tests. Otherwise i'll set a tornado on you
• It's own readme (following contributing guidelines)

Summary

What:

Write CORS middleware tutorial.

Why:

Make it easily digestible by readers.

Acceptance Criteria

Below is a list of tasks that must be completed before this issue can be closed.

• Write documentation

Summary

What:

Write tests for tengine, then enable this in the ci

Why:

There seems to be no tests written

Acceptance Criteria

Below is a list of tasks that must be completed before this issue can be closed.

• Write tests

Summary

What: Add bodyguard middleware, using https://github.com/helmetjs/helmet as inspriation

We don't have to use bodyguard as the name, but it was just something that popped up that was unique. Could also use "guard", "armor", or "shield" or something

Why: We get to have a really cool name... oh and it would be a good utility for users

Acceptance Criteria

• Develop middleware
• Tests. No tests then i'll give you knuckle sandwich
• it's own readme (follow contributing guidelines)

Summary

Tengine is incorrectly referencing drash.

Steps To Reproduce The Bug

1. Run the following

import { Tengine } from "https://deno.land/x/[email protected]/tengine/mod.ts";

2. Stare at the error.

Expected Behavior

Tengine should be able to import Drash.

Suggested Solution(s)

Reference Drash from deps.

Screenshots

Summary

What: If you run deno lint, we will most likely have a whole bunch of errors. This issue to fix these errors by correctly formatting code, and abiding by Deno's standards

Why: It would be good to make sure the code follows either: Deno's best practices, coding standards, or general best practices. It's a Deno project so it makes sense to utilise their tools on making the code Deno-like

Acceptance Criteria

• deno lint is added to the master.yml CI, as a new block (similar to how we use deno fmt --check on some repositories)
• deno lint produces no errors

Resources

Deno Lint Documentation

Summary

What:

Write Jae tutorials.

Why:

Currently, the https://drash.land/drash docs include a front-end section in the sidebar. That content should be moved over to this repository -- keeping the tutorial format. There's no need to keep the front-end section in the Drash documentation pages because the front-end is handled by Tengine now.

Acceptance Criteria

Below is a list of tasks that must be completed before this issue can be closed.

• Write documentation
• Add files to bumper CI

Summary

What:

Remove the static paths middleware from deno-drash and make it useable as middleware. See drashland/drash#454

Why:

Serving static paths is not part of Drash's core.

Acceptance Criteria

Below is a list of tasks that must be completed before this issue can be closed.

• Write migration guide
• Write documentation
• Write unit tests
• Write integration tests
• Include in bumper service

Example Pseudocode

import { ServeStatic } from "...";

const s = new ServeStatic({
  root_directory: Deno.realPathSync("."),
  static_paths: {
    "/some-uri": "/some-physical-path"
  }
});

Summary

What: Morgan logger similar to expressjs/morgan

Why: Easily plug in logging functionality to a Drash application.

Acceptance Criteria

• Docs
• Tests

Summary

Hi 👋

I am one of the maintainers of the Eta template engine. I am just wondering why in the documentation for using it is the import importing v1.6.0 when v1.11.0 is the latest.

Dependencies

drashland/drash#413

This issue cannot be completed until the above issue is closed out.

Summary

What: Be able to write TypeScript on the front-end, have it be compiled, then serve it as JavaScript on the front-end (since browsers don't support TypeScript).

Why: The majority population in the Deno community uses TypeScript. It would be nice to be able to write front-end TypeScript and have it be served as JavaScript in the browser.

Acceptance Criteria

• Middleware that compiles TypeScript to JavaScript and sends that JavaScript as the response body -- allowing browsers to request TypeScript files, but receive JavaScript responses.
• Documentation
• Tests
• Complete dependencies

Update Rhum to the latest version so that it doesn't import deno std 0.82.0.

Summary

What:

Paladin's function is large. Break it down.

Why:

Readability for newcomers. We're going with an object of key value pairs so that we can easily see which headers are mapped to which functions. This will also make it easier for newcomers to see what headers are mapped to what functions. See discussion below for more context surrounding this issue.

Acceptance Criteria

• Break down the function into smaller functions
• Write unit tests

Taking on this issue? Read this before you get started.

If you take on this issue and the acceptance criteria does not make sense, post comments on this issue with your questions. Also, you can always hop in the Discord channel at https://discord.gg/c5R3sYuR to get help quickly.

Please read the Contributing Guidelines before starting this issue.

Summary

What: Add master workflow to run tests on all middlewares, with each new middleware a new test command is added

Also add bumper workflow

Add CI to run tests. Similar to https://github.com/drashland/deno-drash/.github/workflows/master.yml

Update DEV.md to include updating the deno version in that script (if needed)

Add documentation (in the most relevent place) that on each new middleware, to add the tests to the CI

Ensure each middleware gives information about running it's tests (and that would be how the CI runs the tests for each middleware)

Why: Automation, and a badge.

Acceptance Criteria

• Master workflow to run tests of dexter on push
• Update CONTRIVUTING.md to mention to use Rhum when testing (?)
• Update CONTRIBUTING.md to mention to add the test command for a new middleware, into the workflow

Example Pseudo Code (for implementation)

- name: Run dexter Tests
  ...
- name: Run <middleware> Tests
  ...

I think deps.ts runs the old version of Drash 1.3.1.
Can you please fix it to the latest version?

https://deno.land/x/[email protected]/deps.ts

Summary

What: Add vhost middleware, using http://expressjs.com/en/resources/middleware/vhost.html as inspriation

Why: Would be a good utility to give to users

Acceptance Criteria

• develop middleware
• Tests. If there are no tests then i'll make you listen to "Never gonna give you up" on repeat for 10 hours straight
• it's own readme (following contributing guidelines)

Example Pseudo Code (for implementation)

// Add example pseudo code for implementation

https://github.com/drashland/deno-drash-middleware/blob/master/cors/README.md

Summary

What: Add CSRF middleware, using http://expressjs.com/en/resources/middleware/csurf.html as inspiration. luckily, drash already has cookies as a feature

Maybe we could have a unique name, like express has csurf, we could have DCSRF or something

Why: Would be a good middleware to supply users with

Acceptance Criteria

• Develop middleware
• Tests! No tests means you ❤️ package.json, and you wouldn't want that would you...
• It's own readme (use contributing guidelines)

• Add CI to run tests. Similar to https://github.com/drashland/deno-drash/.github/workflows/master.yml

• Update DEV.md to include updating the deno version in that script (if needed)

• Add documentation (in the most relevent place) that on each new middleware, add running it's test to the CI

• Ensure each middleware gives information about running it's tests (and that would be how the CI runs the tests for each middleware)

Summary

In CSRF doc, the expected status for no-token/invalid-token cases are:

If no header/token was passed in, Drash throws a 400.

If the request token does not match what's in csrf.token, then Drash throws a 403.

However, 400 was thrown for invalid token while 403 was thrown when no token.

Expected Behavior

Throw correct status and message for the cases.

Summary

What:

Add requestUID (or similar) middleware. Take inspiration from: http://expressjs.com/en/resources/middleware/connect-rid.html

Why:

It'd be nice to track requests by an ID for debugging purposes. Also, a request ID would be useful in logs -- filtering logs by request ID.

Acceptance Criteria

• Develop middleware -- taking inspiration from connect-rid
• A VERY DETAILED README (see other middleware READMEs as examples)
• Write unit tests

Taking on this issue? Read this before you get started.

If you take on this issue and the acceptance criteria does not make sense, post comments on this issue with your questions. Also, you can always hop in the Discord channel at https://discord.gg/c5R3sYuR to get help quickly.

Please read the Contributing Guidelines before starting this issue.

Summary

I'm the maintainer of the Eta template engine, and I just released version 1.3.0, which has Deno support. I'd like to integrate Eta with Drash.

What: Add support for the Eta template engine (deno.land)

Why: Eta is written in TypeScript, very reliable, highly performant, and supports plugins. It's also lightweight and has 0 dependencies.

I think Eta would be a great fit for Drash, and I'd love to give developers an easy way to use Eta with Deno.

Summary

What: Video tutorial (acts of visual documentation) for how to use Drash's template engine (rendering, creating, extending etc), how it works, how to use them etc - acting as the documentation but in video form. Though it's open to whoever takes on this issue how they'd like to do the video and what content it will have.

Could be useful to include in the description of the video, times of topics, eg:

0:00 - introduction
0:23 - what is the template engine
5:10 - creating a view

Why: Supports visual learners, and thus creates another platform for people to understand Drash's template engine and how to use it - further enforcing "documentation driven"

Information

• OBS can be used as the software to screenshare and video recording

• Includes the drashland introduction? (speak to @crookse)

• Includes the drash logo with the greenish background as the thumbnail

• Video can be added to a "Drash" playlist (can also be created if it doesn't exist)

• Make it chill :)

Updates

• feat: Tengine - A template engine middleware (#62)
• feat: ServeTypeScript - Write front-end TypeScript (#60)
• feat: Add cookie support for CSRF (#57)
• chore: Complete CI (#63)

To support users outside of Drashland, add documentation on where and how to create middlewares. For example, explain:

• File structure for new middlewares
• Usage of 3rd party modules
• Importing and exporting

This would also serve as self documentation for people within Drashland.

Summary

What: Develop timeout middleware, using http://expressjs.com/en/resources/middleware/timeout.html as inspiration

Why: Would be a good middleware to supply users with

Acceptance Criteria

• develop middleware
• Tests = pass; No tests = fail;
• It's own readme (following contributing guidelines)

Dependents

drashland/drash#399

The above issue is dependent on this feature.

Summary

What: Create a template engine middleware that maps Drash's render method to any template engine's render method -- allowing users to use the template engine of their choice.

Acceptance Criteria

• README documentation
• Add Eta tutorial (See #54 for discussion surrounding Eta)
• Add Drake tutorial
• Add to main README
• Tests