luau-lang/rfcs
1
0
Fork 0
mirror of https://github.com/luau-lang/rfcs.git synced 2025-05-04 10:43:48 +01:00
Code Issues Projects Releases Packages Wiki Activity

Nit: "require statements" -> "require expressions"

Browse source
This commit is contained in:
Varun Saini 2024-09-24 11:03:40 -07:00
parent efd404fab3
commit f198bd0a46
1 changed files with 7 additions and 7 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

14
docs/amended-require-resolution.md
View file

@ -2,7 +2,7 @@
## Summary ## Summary
We need to finalize a syntax for aliases in require statements and determine intuitive resolution semantics as we prepare to build a package management system. We need to finalize a syntax for aliases in require expressions and determine intuitive resolution semantics as we prepare to build a package management system.
## Motivation ## Motivation
@ -67,7 +67,7 @@ After a package manager has been implemented, we will likely have a better sense
### Removing `paths` ### Removing `paths`
As part of the push to make require statements more explicit, we will remove `paths`, as aliases defined in `aliases` serve a similar purpose and are more explicit. As part of the push to make require expressions more explicit, we will remove `paths`, as aliases defined in `aliases` serve a similar purpose and are more explicit.
### Throw an error if multiple files matched ### Throw an error if multiple files matched
@ -99,7 +99,7 @@ Conflict between `module` directory and `module.luau`:
## Drawbacks ## Drawbacks
The main drawback of this approach is that it is quite strict and not backwards-compatible with any existing code that uses unprefixed require statements. The main drawback of this approach is that it is quite strict and not backwards-compatible with any existing code that uses unprefixed require expressions.
However, because of its forwards compatibility with approaches (1a) and (1b), it is possible for us to relax these restrictions in the future. However, because of its forwards compatibility with approaches (1a) and (1b), it is possible for us to relax these restrictions in the future.
From an aesthetic point of view, this approach is slightly more cluttered than other approaches, as every path must begin with a prefix. From an aesthetic point of view, this approach is slightly more cluttered than other approaches, as every path must begin with a prefix.
@ -119,7 +119,7 @@ Rather than making an arbitrary decision now, it makes more sense for us to choo
#### (1a) Make aliases explicit with `@` prefix #### (1a) Make aliases explicit with `@` prefix
We make usage of the `@` prefix necessary in aliased require statements. We make usage of the `@` prefix necessary in aliased require expressions.
This means that any unprefixed string is always treated as an unaliased path. This means that any unprefixed string is always treated as an unaliased path.
```luau ```luau
-- Requires ./libs/dependency.luau -- Requires ./libs/dependency.luau
@ -132,13 +132,13 @@ require("./libs/dependency")
require("@libs/dependency") require("@libs/dependency")
``` ```
The main drawback of this approach is that projects with many _external_ dependencies will have many `@` symbols appearing within require statements. The main drawback of this approach is that projects with many _external_ dependencies will have many `@` symbols appearing within require expressions.
This is similar to [Lune's approach](https://lune-org.github.io/docs/getting-started/2-introduction/8-modules#file-require-statements) and is identical to the approach currently described in [require-by-string-aliases.md](require-by-string-aliases.md). This is similar to [Lune's approach](https://lune-org.github.io/docs/getting-started/2-introduction/8-modules#file-require-statements) and is identical to the approach currently described in [require-by-string-aliases.md](require-by-string-aliases.md).
#### (1b) Make relative paths explicit with `./` prefix #### (1b) Make relative paths explicit with `./` prefix
We make usage of the `./` prefix necessary in relative require statements. We make usage of the `./` prefix necessary in relative require expressions.
This means that any unprefixed string is always treated as an aliased path. This means that any unprefixed string is always treated as an aliased path.
```luau ```luau
-- Requires /My/Libraries/Directory/dependency.luau -- Requires /My/Libraries/Directory/dependency.luau
@ -151,7 +151,7 @@ require("./libs/dependency")
require("@libs/dependency") require("@libs/dependency")
``` ```
The main drawback of this approach is that projects with many _internal_ dependencies will have many `./` symbols appearing within require statements. The main drawback of this approach is that projects with many _internal_ dependencies will have many `./` symbols appearing within require expressions.
This is similar to [darklua's approach](https://darklua.com/docs/path-require-mode/). This is similar to [darklua's approach](https://darklua.com/docs/path-require-mode/).