bentoumitech / denox Goto Github PK

Issue Type

• Bug Report
• Feature Request
• Other

Expected

Denox could run a denox option to create a better shorthand command.
The "run" word could be preserved. as optional

denox start

denox run start

Actual

denox run start

Possible Solutions

Could fork the project to start this feature.
BTW, Awesome Library! I was searching for something like this

Info

• DenoX version:
  denox/0.3.0 darwin-x86_64 deno-1.0.0

Issue Type

• Feature Request

Add a new args string array property to workspace.globals and workspace.scripts[scriptName].

This would allow default arguments to be appended to the interpolated command. Here are some examples:

Script:

scripts:
  develop:
    file: main.ts
    args:
      - hello
globals:
  deno_options:
    allow-read: true

> denox run develop
# equal to:
# deno run --allow-read main.ts hello

> denox run develop more args
# equal to:
# deno run --allow-read main.ts hello more args

Global:

scripts:
  develop:
    file: main.ts
globals:
  args:
    - foo bar
    - baz
  deno_options:
    allow-read: true

> denox run develop
# equal to:
# deno run --allow-read main.ts "foo bar" baz

> denox run develop more args
# equal to:
# deno run --allow-read main.ts "foo bar" baz more args

Both: (script replaces global, like with deno_options)

scripts:
  develop:
    file: main.ts
    args:
      - nice to
      - meet you
globals:
  args:
    - foo bar
    - baz
  deno_options:
    allow-read: true

> denox run develop
# equal to:
# deno run --allow-read main.ts "nice to" "meet you"

> denox run develop more args
# equal to:
# deno run --allow-read main.ts "nice to" "meet you" more args

Issue Type

• Bug Report
• Feature Request
• Other

Expected

src/tsconfig.app.json

{
  "compilerOptions": {
    "experimentalDecorators": true,
    "emitDecoratorMetadata": true
  }
}

deno-workspace.yml

scripts:
  # deno run --allow-net --allow-read --config ./src/tsconfig.app.json app.ts
  # deno run --allow-net --allow-read --config=./src/tsconfig.app.json app.ts
  start:
    file: app.ts
    deno_options:
      allow-net: true
      allow-read: true
      config: ./src/tsconfig.app.json
  develop:
    file: main.ts
  globals:
    deno_options:
      allow-read: true

Expected to execute like: deno run --allow-net --allow-read --config ./src/tsconfig.app.json app.ts

> denox run start
Compile https://deno.land/[email protected]/fmt/colors.ts
register Controller:  HomeController
register route:  /home/text
register route:  /home/json
Server start in :8000

Actual

Actual to execute like: deno run --allow-net --allow-read "--config ./src/tsconfig.app.json" app.ts

> denox run start
error: Found argument '--config ./src/tsconfig.app.json' which wasn't expected, or isn't valid in this context
        Did you mean --config?

USAGE:
    deno run <SCRIPT_ARG>... --allow-net=<allow-net> --allow-read=<allow-read> --config <FILE>

For more information try --help

Possible Solutions

I tried to revise the spacer of the config from " " to "=", it seems could be a workaround. I tested it, it seems working fine. But I am not sure is there is another way to let the --config argument not to combine with --config as a string.

yihua1218@c9e3686

Info

• DenoX version: denox/0.3.0 darwin-x86_64 deno-1.0.0

【Bug】deno throw error

• Bug Report

`
Check https://denopkg.com/BentoumiTech/denox/denox.ts
error: TS1205 [ERROR]: Re-exporting a type when the '--isolatedModules' flag is provided requires using 'export type'.
export { ParseOptions, parse, parseAll } from "./yaml/parse.ts";
~~~~~~~~~~~~
at https://deno.land/[email protected]/encoding/yaml.ts:6:10

TS1205 [ERROR]: Re-exporting a type when the '--isolatedModules' flag is provided requires using 'export type'.
DumpOptions as StringifyOptions,

  at https://deno.land/[email protected]/encoding/yaml.ts:8:3

TS1205 [ERROR]: Re-exporting a type when the '--isolatedModules' flag is provided requires using 'export type'.
DenoWorkspace,
~~~~~~~~~~~~~
  at https://raw.githubusercontent.com/BentoumiTech/denox/master/src/interfaces.ts:25:3

TS1205 [ERROR]: Re-exporting a type when the '--isolatedModules' flag is provided requires using 'export type'.
WorkspaceGlobal,
~~~~~~~~~~~~~~~
  at https://raw.githubusercontent.com/BentoumiTech/denox/master/src/interfaces.ts:26:3

TS1205 [ERROR]: Re-exporting a type when the '--isolatedModules' flag is provided requires using 'export type'.
WorkspaceScript,
~~~~~~~~~~~~~~~
  at https://raw.githubusercontent.com/BentoumiTech/denox/master/src/interfaces.ts:27:3

TS1205 [ERROR]: Re-exporting a type when the '--isolatedModules' flag is provided requires using 'export type'.
WorkspaceOptions,
~~~~~~~~~~~~~~~~
  at https://raw.githubusercontent.com/BentoumiTech/denox/master/src/interfaces.ts:28:3

TS1205 [ERROR]: Re-exporting a type when the '--isolatedModules' flag is provided requires using 'export type'.
DenoOptionsEntries,
~~~~~~~~~~~~~~~~~~
  at https://raw.githubusercontent.com/BentoumiTech/denox/master/src/interfaces.ts:29:3

TS1205 [ERROR]: Re-exporting a type when the '--isolatedModules' flag is provided requires using 'export type'.
DenoOptionValue,
~~~~~~~~~~~~~~~
  at https://raw.githubusercontent.com/BentoumiTech/denox/master/src/interfaces.ts:30:3

TS1205 [ERROR]: Re-exporting a type when the '--isolatedModules' flag is provided requires using 'export type'.
export { getOptionType, OptionTypeValues };
                      ~~~~~~~~~~~~~~~~
  at https://raw.githubusercontent.com/BentoumiTech/denox/master/src/deno_options/utils.ts:40:25

TS1205 [ERROR]: Re-exporting a type when the '--isolatedModules' flag is provided requires using 'export type'.
export { buildDenoCLIOptionsArgs, CLIArgument };
                                ~~~~~~~~~~~
  at https://raw.githubusercontent.com/BentoumiTech/denox/master/src/deno_options/build_cli_arguments.ts:75:35

Found 10 errors.

`

## Info

- DenoX version: @last version

Issue Type

• Other (Documentation)

I see there is resolution logic for this, but it is not yet documented.

Ref. source:

I think it would be good to reconsider the resolution order based on some rules. This is how ESLint does it. Here is a suggested idea with included reasoning:

(Don't support extensionless deno-workspace because of ambiguity — but if you feel strongly about this, explain clearly which format(s) are valid without an extension, e.g. yaml/json)

1. First, files that begin with deno-workspace (not dotfiles because in the event of a conflict, the dotfile is potentially hidden and could be a surprise).

2. Next, in the following extension order, preferring more human-readable formats and static files, which offer better security at the cost of flexibility (more on this below):

   • .yaml
   • .yml
   • .json
   • (no extension would go here if it is not a script)
   • .ts
   • .js

3. Files that begin with .deno-workspace following the same extension order as above

So, the suggested order would be:

• deno-workspace.yaml
• deno-workspace.yml
• deno-workspace.json
• deno-workspace (if it is not a script)
• deno-workspace.ts
• deno-workspace.js
• .deno-workspace.yaml
• .deno-workspace.yml
• .deno-workspace.json
• .deno-workspace (if it is not a script)
• .deno-workspace.ts
• .deno-workspace.js

Security

It appears that when evaluating workspace script files, they are evaluated with the permissions inherited from denox, which is suggested to be --allow-all at installation. Is that correct? If so, that could be very dangerous.

Static configuration files are easier to reason about than dynamic scripts, so they are easier to secure.

Issue Type

• Feature Request

This screenshot is shown in the readme:

After running the command, it shows this text in stdout:

Running main script with allow-read, seed and reload options ...

This doesn't appear in the current version of denox. I don't know why for certain, but I agree that it shouldn't be in stdout for multiple reasons.

However, this is the core functionality of denox: to interpolate commands for proxying to deno.

It would be extremely useful for denox to provide the interpolated command strings using a prefix like command, for example:

deno-workspace.yaml

scripts:
  main:
    file: main.ts
    deno_options:
      allow-net: example.com
      unstable: true

> denox command run main script args
deno run --allow-net=example.com --unstable main.ts script args

This would be useful for understanding how denox is parsing the workspace file and could potentially help to debug denox in the future.

Info

• DenoX version: 0.4.0

Issue Type

• Bug Report
• Feature Request
• Other

Possible Solutions

scripts:
  # "denox run start" will execute main.ts with example.com networking permissions
  start:
    file: main.ts
    env:
      PORT: 80
      DOMAIN: "example.net"
    deno_options:
      allow-net: example.com
  # "denox run develop" will execute main.ts with localhost networking permissions and source code cache reloaded
  develop:
    file: main.ts
    env:
      PORT: 3000
      DOMAIN: "localhost"
    deno_options:
      allow-net: localhost
      reload: true

Then it would add the variables to Deno using Deno.env.set('NAME', 'VALUE')
Then we can access it via Deno.env.get("NAME")

It would require --allow-env to be set.

Issue Type

• Bug Report
• Feature Request
• Other

Summary

Firstly, this is a great package, it's great to see deno being used in the wild. Something I've missed (moving from Node) is the ability to execute inline scripts.

Several of our projects use scripts to build, package and deploy using yarn (or npm). This allows developers to store complex scripts and execute them when they aren't directly related to the src code but perform repetitive tasks.

These tasks would otherwise have to be remembered or stored in the project. I have resorted to creating a ./scripts directory in the project root. However, this feels like unnecessary noise for administrative scripts

My proposal would be to introduce the ability to either execute a cmd or a file by checking the file or cmd flag on the deno_workspace file.

Possible Solutions

There are several requirements for this:

1. There would have to be a check to see if the user was trying to execute a cmd/script or a file script in the _runScript.
2. We would need to replace whatever env variables were being placed into the script (as this is a common occurrence).
3. It would have to work for both deno inline script execution and some arbitrary script execution.

If I have forgotten anything let me know. I have put together a pull request and added the relevant tests. This is more of a placeholder until the env var issue has been introduced. I think there might be an opportunity to create further test penetration on the run.ts file.

async function _runScript(
  scriptName: string,
  args: string[],
): Promise<{ code: number }> {
  const workspace = await loadDenoWorkspace();

  const workspaceScript = workspace.scripts[scriptName];
  const workspaceGlobal = workspace?.globals || {};

  if (workspaceScript === undefined) {
    throw new ScriptNotFoundError(scriptName);
  }

  return workspaceScript.file
    ? await _runDenoFile(workspaceScript, workspaceGlobal, args)
    : await _runInlineScript(workspaceScript, args);
}

async function _runInlineScript(
  workspaceScript: WorkspaceScript,
  workspaceGlobal: WorkspaceOptions,
  args: string[],
): Promise<{ code: number }> {
  const cmd: any[] = workspaceScript.cmd?.split(' ').concat(args) || [];
  const [mainScript]: string = cmd;

  // If the first argument is deno then we want the deno options.
  if (mainScript === 'deno') {
    const denoOptions = await _getDenoOptions(workspaceScript, workspaceGlobal);

    cmd.concat(denoOptions);
  }

  const process = Deno.run({
    cmd
  });

  const { code } = await process.status();

  return { code };
}

Again, thanks for the great project.

Issue Type

• Bug Report
• Feature Request
• Other

Expected

Actual

Possible Solutions

Info

The only version that "somehow" works is 0.4.1 from Cyberhan123's fork, and running denox run <script> says that missing deno-workspace file, but I'm using scripts.json... and also an error with the denox init command...

• DenoX version:

Issue Type

• Question

Description

Looking at these issues: Link 1, Link 2, Link 3 and more, there seems to be a general interest for a better system of managing dependencies and permissions. While I don't really have any opinions on whether that's necessary or how they should be elegantly implemented, the current recommendation is to create a deps.ts or import_map.json file to manage your dependencies from a centralised location while cleaning up your import statements.

A denox add command would be useful to automatically add new dependencies to an import map, either in the deno-workspace file or a separate import_map.json file. The denox run command could then include this import map when running a script (perhaps this could be the default behaviour with an option to opt-out of it with a flag).

Adding them to the workspace file would mean that denox doesn't have to deal with a second file, but then the import maps cannot be directly used by the standard deno CLI with the --import-map option. Also, I would assume that this would have to be limited to JSON and YML workspace files.

Thoughts? If this seems in line with the goal of this project, I'd be interested in working on a PoC.

Issue Type

• Feature Request

It appears that one of the primary goals of this project is to reduce typing. I think every programmer loves that.

It might be possible to allow for even terser syntax by establishing and documenting some sensible defaults and inference behavior. Here are some suggested considerations:

Default script:

For example, one could use the command denox run, which would be expanded to denox run default. (I gave default as the example here, but maybe you like main, etc.)

Example:

deno-workspace.yaml

scripts:
  default:
    file: main.ts
    deno_options:
      allow-net: example.com

shell

> denox run
# equal to:
# deno run --allow-net=example.com main.ts

Inferring file from script:

Likewise, in deno-workspace.scripts:
If a script does not provide a value for file, it could be inferred from its script key—this would allow it to be an optional property if people would like to organize scripts directly by file name. This practice provides the advantage of native terminal tab-completion and also promotes an organizational structure which aligns with the workspace filesystem.

Example:

This:

scripts:
  main.ts:
    file: main.ts
    deno_options:
      allow-net: example.com

could be equal to:

scripts:
  main.ts:
    deno_options:
      allow-net: example.com

Pagic is a static site generator powered by Deno + React

Here are some demos:

• pagic.org
• Deno X ranking
• TypeScript 入门教程

If it is possible to use pagic to build the website, I would like to create the pull-request

Issue Type

Bug Report:

Actual

I tried running it locally and it says this:

It thinks the url is from github for some reason and does not recongize my local file??

Info

• DenoX version: latest
  Edit: Forgot to mention im using WSL (Windows Subsystem for Linux)

Issue Type

• Feature Request

It appears that currently denox supports only proxying the deno run command. Are there plans to implement other commands like deno info, deno repl, deno eval, etc? If so, are the plans on a roadmap somewhere?