Skip to content
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

Bash Executable Types #42212

Closed
5 tasks done
jamiebuilds opened this issue Jan 5, 2021 · 13 comments
Closed
5 tasks done

Bash Executable Types #42212

jamiebuilds opened this issue Jan 5, 2021 · 13 comments
Labels
Out of Scope This idea sits outside of the TypeScript language design constraints Suggestion An idea for TypeScript

Comments

@jamiebuilds
Copy link

Suggestion

πŸ” Search Terms

List of keywords you searched for before creating this issue. Write them down here so that others can find this suggestion more easily and help provide feedback.

  • Bash
  • Shellscript

βœ… Viability Checklist

My suggestion meets these guidelines:

  • This wouldn't be a breaking change in existing TypeScript/JavaScript code
  • This wouldn't change the runtime behavior of existing JavaScript code
  • This could be implemented without emitting different JS based on the types of the expressions
  • This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)
  • This feature would agree with the rest of TypeScript's Design Goals.

⭐ Suggestion

A hot new way of constructing types at build time using the worlds most universally beloved language: bash.

Using the bash`...` type you can now run entire bash programs inside of TypeScript.

type FileName = bash`
  find "$PWD"
`

The bash template type constructor would create a union of every stdout line of the embedded bash program.

πŸ“ƒ Motivating Example

Before: Allows all sorts of strings, who knows if this will work at runtime.

async function readFile(fileName: string) {
  // ...
}

After: Only real files can be read from the file system, now you can sleep at night

type FileName = bash`
  find "$PWD"
`

async function readFile(fileName: FileName) {
  // ...
}

πŸ’» Use Cases

  • Type-safe file operations
  • Keeping your database in sync with your types
  • Running Docker inside TS so your types are reproducible
  • Fork bombing VSCode
@DanielRosenwasser
Copy link
Member

*checks date* I think you have confused 1/4/2021 and 4/1/2021 πŸ˜…

@jamiebuilds
Copy link
Author

There's another use case! A whole bunch of people need to be reminded to update their copyright year strings, now they can automate that reminder with $ date

type Year = bash`
  date +"%Y"
`

type Copyright = `Copyright Β© ${Year} Company, Inc.`


function Footer() {
  let copyright: Copyright = "Copyright Β© 2020 Company, Inc." // ERROR!!!! Happy 2021!!!
  return <p>{copyright}</p>
}

@jamiebuilds
Copy link
Author

People have pointed out some valid security concerns with third-party dependencies using their own bash types to steal private company code. My advice is add a new entrypoint to your program which turns networking features off, thereby thwarting any and all hacking attempts that steal data.

// safe-entry.ts
type main = bash`
  nmcli networking off
  node ./unsafe-entry.ts
  nmcli networking on
`

@RyanCavanaugh
Copy link
Member

This all makes sense and has no downsides, but I'm trying to figure out why bash instead of Powershell

@ghost
Copy link

ghost commented Jan 5, 2021

Why use a specific scripting language that a user may or may not have, instead of, say, TypeScript?

This could be generalized into compile-time TS execution, we already sorta have it for const enums, why not just expand it to include everything?

Otherwise, this cannot possible be available everywhere anyways, ex: https://typescriptlang.org/play couldn't execute Bash :/
And fork bombing VSC on Windows would be cool, but it can't happen in Bash.

@jamiebuilds
Copy link
Author

I'm trying to figure out why bash instead of Powershell

"bash" has fewer characters than "powershell" so users will save on file storage

@jamiebuilds
Copy link
Author

Why use a specific scripting language that a user may or may not have, instead of, say, TypeScript?

Users can call out to ts-node from bash. By allowing bash you're actually allowing any other language of your choice!

this cannot possible be available everywhere anyways, ex: typescriptlang.org/play couldn't execute Bash :/

To be clear, I would expect TypeScript to ship its own copy of Bash for security reasons (who knows what a bad actor may do to /bin/bash)

@MartinJohns
Copy link
Contributor

MartinJohns commented Jan 5, 2021

This is somewhat related to #39385, where @RyanCavanaugh wrote:

Executing user code during compilation time is the first step toward madness; we don't implement features like this and don't intend to.

Just here the "user code" is bash, not TypeScript, and it's intended for types.

@jamiebuilds
Copy link
Author

Just here the "user code" is bash

aha see, therefore it is superior

@MartinJohns
Copy link
Contributor

I have to admit that I completely missed the joke.

@RyanCavanaugh RyanCavanaugh added Out of Scope This idea sits outside of the TypeScript language design constraints Suggestion An idea for TypeScript labels Jan 5, 2021
@RyanCavanaugh
Copy link
Member

Tagging "Out of Scope" but let's agree that tag actually means "Too powerful for mere mortals to wield" in this case

@weswigham
Copy link
Member

(But to the people in this thread saying "why not define the type computation in TypeScript": I've very much toyed with the idea)

@typescript-bot
Copy link
Collaborator

This issue has been marked as "Out of Scope" and has seen no recent activity. It has been automatically closed for house-keeping purposes.

@typescript-bot typescript-bot closed this as not planned Won't fix, can't repro, duplicate, stale Jun 21, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Out of Scope This idea sits outside of the TypeScript language design constraints Suggestion An idea for TypeScript
Projects
None yet
Development

No branches or pull requests

6 participants