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

type annotation #1233

Open
Freed-Wu opened this issue Nov 28, 2024 · 0 comments
Open

type annotation #1233

Freed-Wu opened this issue Nov 28, 2024 · 0 comments
Labels
enhancement New feature or request

Comments

@Freed-Wu
Copy link

Freed-Wu commented Nov 28, 2024

What is the problem this feature will solve?

Many LSP support type annotations. Such as:

Is it possible to support type annotations for bash? e.g.,

# This should be a brief description of the package and its functionality. Try
# to keep the description to one line of text and to not use the package's name.
#@type string
pkgdesc='default value'

# Defines on which architectures the given package is available (e.g.,
# arch=(i686 x86_64)). Packages that contain no architecture specific files
# should use arch=(any). Valid characters for members of this array are
# alphanumerics and "_".
#@type string[]
arch=()

If we write arch=x86_64 we will get error.
except we change string[] to string[] | string or string[] | 'x86_64'

And we will get document hover from the comment before variable.

And we can introduce more types. like 'true' | 'false' for bool, /\d+/ for number.
@param 1: 'true' | 'false' for function input $1. Even we can define new types. like:
@typedef boolean: 'true' | 'false'

What is the feature you are proposing to solve the problem?

type annotation

What alternatives have you considered?

termux-language-server use json schema to annotate type of variables. However, it is specific, not flexible.
For PKGBUILD, there is a PKGBUILD.json.
If we realize type annotation, we can use PKGBUILD.d.sh, %.ebuild.sh, build.sh.d.sh for PKGBUILD, ebuild, build.sh.
We even can introduce some magic comments. e.g., we add #@source PKGBUILD.d.sh to test.sh, it will use types of PKGBUILD.d.sh.
or #@source https://a_URL_like_DefinitelyTyped/PKGBUILD.d.sh.

*.d.sh is like *.d.ts. It is also helpful for other projects like shellcheck.

And some bash script provide some function as a wrapper of source. such as ebuild's inherit.

If we inherit toolchain-funcs, it will source $EPREFIX/var/db/repos/gentoo/eclass/toolchain-funcs.eclass and user can use the functions defined toolchain-funcs.eclass. we can use the code
in %.ebuild.d.sh:

inherit() {
  source $EPREFIX/var/db/repos/gentoo/eclass/$1.eclass
}

Like after import XXX then use functions defined in XXX.py? Attractive and a little hard to realize?

Just my 2c. Welcome to discuss!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant