The runex from karfau

Dependency Dashboard

This issue lists Renovate updates and detected dependencies. Read the Dependency Dashboard docs to learn more.

Rate-Limited

These updates are currently rate-limited. Click on a checkbox below to force their creation now.

Open

These updates have all been created already. Click a checkbox below to force a retry/rebase of any.

chore(deps): update dependency node to v14 (node, @types/node)

Ignored or Blocked

These are blocked by an existing closed PR and will not be recreated unless you click a checkbox below.

Detected dependencies

github-actions

.github/workflows/nodejs.yml

actions/checkout v3

actions/setup-node v3

npm

examples/npx-require/package.json

examples/num-args/package.json

package.json

commander 5.1.0

@types/node 13.13.2

codecov 3.8.3

np 7.6.2

tap 14.10.7

testdouble 3.16.8

ts-node 10.9.1

typescript 3.9.10

nvm

.nvmrc

node 10.24

Check this box to trigger a request for Renovate to run again on this repository

Some questions and Ideas

I found your question in the npx repo and found this repo, but I have a few questions.

Background

I'm working on various dev-utilities because many of the commonly used ones were designed around archaic JS/ES functionalities and are often incompatible with (or not worth the effort to make them work with) my es2020/esNext projects.

Currently my focus is around:

improved integration and simplified usage of package(-lifetime)-scripts and shell-like scripting

Package scripts are an incredible tool for both development and in deployment but setting them up is complex and time consuming and creating a good default implementation is even harder. so I've been experimenting around and I think using small and standardized modules that can be scripted and used programmatically as needed is the smartest way to go.

One thing I think this could enable are small scripts and services able to work together and independently, sharing data in a loose swarm where both shell-like scripting and programmatic usages can work together to be both flexible and not configuration intensive. this would be the holy grail, but this will be incredibly hard to make functional.

simplifying dependency maintenance and dep-tree integrity to avoid Dependency-Hell

Many parts of the JS ecosystem are stuck in a dependency-hell, because they were started when invariance of packages was the common way to ensure stability in programming. The language and its foundations have been advancing at high speed for many years now, yet this principle of invariance is still common and techniques that have been considered bad practice for years or have much much simpler modern alternatives are still regularly recommended all over the place.

It would be great for new projects to be as easy as possible to modernise as they age. I think the smart way to do that is focusing on easy adaptability instead of base-level compatibility and on creating flexible interfaces that can be switched out easily if needed and basing convention at this top-layer instead.
Pressuring users to update/-grade constantly by issuing deprecation early, and making it easy to do so is the smart move now.
for this it's important to look at the upcoming changes in the language and your frameworks and prepare ahead of time to adapt as soon as possible so the user has the ability to do the same.

general maintenance automation based on and around a modern infrastructure

The physical infrastructure has advanced to a point where resources for programming is abundant. Bandwidth is large enough to support updating something for even the most minor changes, and processing power is plenty enough to do so passively with negligible performance impact instead of on-use.

For this I plan on working on a way to include micro-services seamlessly in a project with similar functionalities as GitHub-actions but for client- and dev-side use instead of in a repository

easier creation and configuration of projects implementing and aiding in creation of the aforementioned points

This is probably the biggest roadblock for me right now. Having a boiler-plate be as current as possible will require adaptive automation, dynamic recommendations and an easier way to configure and initialize complex projects than anything I've found.
For this reason I think my first point is the most urgent.

following

I see you are working on a few similar things and I'd be very interested in exchanging ideas.

on that note, I see that your code base is rather modern. What are your thougts on switching over to using ES-modules? They would solve a couple of the issues you talk about in the readme not with anything that adds complexity but by their very nature. eg.

named import/export can take care of many issues with function naming conventions, as they only need to have consistency at the surface level.
The nature of ESM allows static analyzing across modules and import/export can be automatically and correctly typed by the typescript-language-feature for intellisense and .d.ts-files making very strict convention less relevant.
it is framework independent, stripping one layer of complexity and abstraction.
very little extra code is needed to make a scripts behave consistently on the command line and when used programmatically.
usage of top-level-await: it's still experimental in v8 but it's part of the EcmaScript-standard and it will be implemented consistently on all platforms in the near future. (can be enabled via --harmony-top-level-await)

on a related note, I see that you added typings, you could switch to typescript directly, as with modern ES-features and using vanilla-style typescript and ESM, you can write code that only needs to be stripped of type-annotations to be valid JS/ES-code, this way the .d.ts-files don't have to be written seperatly and the code gets basic documentation as you go, making coding more consistent and modifying code easier and less error-prone.

If you need a more detailed explanation on any of this, feel free to just ask.

and my apologies for writing that much, lol

Stop parsing options after passing runnable in list of arguments

Due to the underlying argument option parser ( the following invocation:
runex -r ts-node/register runnable -r whatever
will not receive the arguments `'-r', 'whatever', and will instead be called with zero arguments (tj/commander.js#1127)
A failing test has already been added to https://github.com/karfau/runex/compare/fix/stop-at-first-positional?expand=1

The workaround for now is to add -- before runnable:
runex -r ts-node/register -- runnable -r whatever

I made an attempt to fix it by moving to yargs-parser but it has other issues.

Currently I'm evaluating the aailable options/arguments for picking the right parser: https://github.com/karfau/node-cli-arguments-options

karfau / runex Goto Github PK

runex's Introduction

Hi there 👋

runex's People

Contributors

Stargazers

Watchers

runex's Issues