-
Notifications
You must be signed in to change notification settings - Fork 13
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Terser syntax through well-documented defaults and inference #16
Comments
With the future possibility to specify |
@BentoumiTech I can see how that would complicate things. However, #19 addresses this. |
|
What the workspace file look like if there was added support for |
Issue Type
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 todenox run default
. (I gavedefault
as the example here, but maybe you likemain
, etc.)Example:
deno-workspace.yaml
shell
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:
could be equal to:
The text was updated successfully, but these errors were encountered: