[12.x] Add `isEmail()` for `Str` and `Stringable` #57049

Rahul-Mac · 2025-09-13T06:18:49Z

This PR introduces a new method to determine if a value is a valid email. Currently, the only way to check this is using the Validator. This change transfers the logic of ValidatesAttributes::validateEmail() into Str::isEmail()

Signature

public static function isEmail(
        \Stringable|string $value,
        bool $rfc = false,
        bool $strict = false,
        bool $dns = false,
        bool $spoof = false,
        bool $filter = false,
        bool $filterUnicode = false,
        array $customValidations = [],
    ): bool {}

Usage

Basic

Str::isEmail('[email protected]'); // true

Str::isEmail('invalid-email'); // false

Validation Mode

Str::isEmail('[email protected]', dns: true); // true

Str::isEmail('test👨‍💻@domain.com', rfc: true); // false

Note

RFC validation will be used by default if all the flags are set to false and there aren't any custom validations added.

`Stringable` class

(new Stringable('[email protected]'))->isEmail(); // true

rodrigopedra · 2025-09-13T07:32:03Z

Attempts just from this year:

Good luck.

Rahul-Mac · 2025-09-13T07:42:51Z

@rodrigopedra So this is the 5th one. Yikes! I wanted this method to exist and use it. Seems like there is a demand for this, although the odds of getting this merged are slim. Anyway, I'll let it stay.

taylorotwell · 2025-09-13T12:27:21Z

src/Illuminate/Support/Str.php

+            return false;
+        }
+
+        $validations = (new Collection($parameters))


I wouldn't use parameters here like we do in validation. You can use named arguments for better readability.

@taylorotwell Should I go for something like this?

public static function isEmail( $value, bool $strict = false, bool $dns = false, bool $spoof = false, bool $filter = false, bool $filterUnicode = false, array $customValidations = [], ) {}

shaedrich · 2025-09-13T13:03:32Z

src/Illuminate/Support/Str.php

+     */
+    public static function isEmail($value, $parameters = [])
+    {
+        if (! is_string($value) && ! (is_object($value) && method_exists($value, '__toString'))) {


Wouldn't testing if the object's class implements Stringable be better?

@shaedrich That sounds better. I'll fix it.

shaedrich · 2025-09-13T13:08:41Z

src/Illuminate/Support/Str.php

+     * Determine if the given value is a valid email.
+     *
+     * @param  mixed  $value
+     * @param  array<int, int|string>  $parameters


@shaedrich Sure, but @taylorotwell said:

I wouldn't use parameters here like we do in validation. You can use named arguments for better readability.

Should I go for this instead?

public static function isEmail( $value, bool $strict = false, bool $dns = false, bool $spoof = false, bool $filter = false, bool $filterUnicode = false, array $customValidations = [], ) {}

Or I'd love a better suggestion than my proposal.

Yeah, Taylor's feedback and your solution look good 👍🏻

You can incorporate my suggestion into this without a problem:

/** * @param class-string[] $customValidations */ public static function isEmail( $value, bool $strict = false, bool $dns = false, bool $spoof = false, bool $filter = false, bool $filterUnicode = false, array $customValidations = [], ) {}

@shaedrich Great! I'll implement all the changes. BTW, may I add type declarations?

public static function isEmail( \Stringable|string $value, // other arguments...

Instead of the if check?

if (! is_string($value) && ! (is_object($value) && $value instanceof \Stringable)) { return false; }

We tend to use native types over PHPDoc ones these days, so that would make sense 👍🏻

shaedrich

@Rahul-Mac I can't approve or reject since I'm not a reviewer, but Taylor will

rodrigopedra · 2025-09-14T21:59:57Z

@Rahul-Mac

You need to move the email validator dependency from the illuminate/validator's composer.json file to the illuminate/support's composer.json file.

For those who use these components outside a Laravel app.

framework/src/Illuminate/Validation/composer.json

Line 21 in d1dc038

"egulias/email-validator": "^3.2.5|^4.0",

…support's composer.json

NickSdot · 2025-09-15T22:20:00Z

Perhaps it should be considered to make it easier to validate a single value in a fluent way in the validator and return the string helper?

After all, this is a string helper, not a string validator. Validator already depends on Support, so there wouldn't be any dependency changes.

Rahul-Mac · 2025-09-16T01:17:22Z

After all, this is a string helper, not a string validator.

@NickSdot Str contains validation methods like isUrl, isJson, etc., and there could be a need to validate an email in a service (I had this problem), so I decided to migrate the logic.

NickSdot · 2025-09-16T01:22:45Z

After all, this is a string helper, not a string validator.

@NickSdot Str contains validation methods like isUrl, isJson, etc., and there could be a need to validate an email in a service (I had this problem), so I decided to migrate the logic.

I know. But they shouldn't be there (at least they don't have dependencies, though). Where does it end? Do we soon have the full validator in the string helper?

shaedrich · 2025-09-16T06:40:13Z

After all, this is a string helper, not a string validator.

I was advocating for reducing the bloat of the string helper, yet to no avail (#52979), so I have to assume, this is by design for a lack of effort to change that.

NickSdot · 2025-09-16T10:48:08Z

After all, this is a string helper, not a string validator.

I was advocating for reducing the bloat of the string helper, yet to no avail (#52979), so I have to assume, this is by design for a lack of effort to change that.

I remember that PR.

Here since Laravel 4. Things got way too overwhelming ever since. In average we added ~42,000 new lines per year since L5.4. And that's just laravel/framework. Str has > 100 methods. PHPdoc doesn't include examples. Navigating in the IDE makes your head want to explode--not only in the string helper, thanks to inheritance.

Now we start to basically "proxy" the validator into the string helper? After this is merged, the rest will follow? How aboutStr::isDate() next? And then range validation for it?

We have so much things in here that people send PRs for methods that already exist. Because no one knows everything anymore. Not even the OGs and Taylor himself (as seen on Twitter).

My personal feeling is that something has to happen, somehow. Maybe a feature freeze year under the theme "let's clean up and reorganise things" would do good. Modernise, type, reduce inheritance, reduce duplication, reduce call stacks, separate concerns, make global helpers namespaced, make IDEs understand Laravel without plugins that make it sweat, etc...

Open a new namespace as a sibling of Illuminate or whatever; then people can opt-in in their own pace. Introduce official rector rules.

This is not me bashing. It's subjective and constructive feedback.

@taylorotwell, you mentioned on Twitter that you are very interested in any feedback. Here is some. 👆

Rahul-Mac · 2025-09-16T11:16:33Z

@NickSdot Your argument is compelling. There are tons of classes that appear bloated but the thing is (correct me if I'm wrong here) that Laravel is more of a "making devs happy & rapidly building code" framework more than a "best practices" framework like Symfony.

Let's face it: Laravel violates a few principles. $request->user() violates SOLID. Ideally, we should inject Auth/Factory Contract to get the user. Almost every framework ends up having a few such issues unless they're truly focused on abiding by the principles.

Personally, if I wanted to follow "best practices", I'd code using Symfony. But Laravel helps me get my work done and provides a certain ease although I do prefer Contracts over Facades.

This helper is something that I felt was needed. Let's see what happens. But I'll keep in mind not to come up with another such helper unless it truly solves a problem.

NickSdot · 2025-09-16T11:23:14Z

@NickSdot Your argument is compelling. There are tons of classes that appear bloated but the thing is (correct me if I'm wrong here) that Laravel is more of a "making devs happy & rapidly building code" framework more than a "best practices" framework like Symfony.

Let's face it: Laravel violates a few principles. $request->user() violates SOLID. Ideally, we should inject Auth/Factory Contract to get the user. Almost every framework ends up having a few such issues unless they're truly focused on abiding by the principles.

Personally, if I wanted to follow "best practices", I'd code using Symfony. But Laravel helps me get my work done and provides a certain ease although I do prefer Contracts over Facades.

This helper is something that I felt was needed. Let's see what happens. But I'll keep in mind not to come up with another such helper unless it truly solves a problem.

Screenshot above shows that devs aren't as happy anymore. My point exactly. I don't even talk about principles here. It's about usability. The Laravel approach worked great for a long time. But now Laravel is a massive framework. It has many many more tools compared to L4. Throwing everything just somewhere like it's a kitchen sink will not age well.

shaedrich · 2025-09-16T12:03:07Z

My personal feeling is that something has to happen, somehow. Maybe a feature freeze year under the theme "let's clean up and reorganise things" would do good. Modernise, type, reduce inheritance, reduce duplication, reduce call stacks, separate concerns, make global helpers namespaced, make IDEs understand Laravel without plugins that make it sweat, etc...

Open a new namespace as a sibling of Illuminate or whatever; then people can opt-in in their own pace. Introduce official rector rules.

This is not me bashing. It's subjective and constructive feedback.

It's great feedback, thanks! 👍🏻 Yeah, that'd be great.

Throwing everything just somewhere like it's a kitchen sink will not age well.

Wholeheartedly agree! 👍🏻

crynobone · 2025-09-18T03:44:11Z

src/Illuminate/Support/composer.json

        "ext-ctype": "*",
        "ext-filter": "*",
        "ext-mbstring": "*",
+        "egulias/email-validator": "^3.2.5|^4.0",


Should just be a suggest:

framework/src/Illuminate/Support/composer.json

Lines 52 to 62 in 280b160

"suggest": {

"illuminate/filesystem": "Required to use the Composer class (^12.0).",

"laravel/serializable-closure": "Required to use the once function (^1.3|^2.0).",

"league/commonmark": "Required to use Str::markdown() and Stringable::markdown() (^2.7).",

"league/uri": "Required to use the Uri class (^7.5.1).",

"ramsey/uuid": "Required to use Str::uuid() (^4.7).",

"symfony/process": "Required to use the Composer class (^7.2).",

"symfony/uid": "Required to use Str::ulid() (^7.2).",

"symfony/var-dumper": "Required to use the dd function (^7.2).",

"vlucas/phpdotenv": "Required to use the Env class and env helper (^5.6.1)."

},

Then Validation/composer.json should keep it as required.

taylorotwell · 2025-09-21T15:31:24Z

Thanks for your pull request to Laravel!

Unfortunately, I'm going to delay merging this code for now. To preserve our ability to adequately maintain the framework, we need to be very careful regarding the amount of code we include.

If applicable, please consider releasing your code as a package so that the community can still take advantage of your contributions!

feat: add isEmail() for Str and Stringable

ad33fdc

Rahul-Mac marked this pull request as draft September 13, 2025 06:22

fix: use Container::getInstance() and apply Laravel's coding style

8efa646

Rahul-Mac changed the title ~~feat: add isEmail() for Str and Stringable~~ feat: add isEmail() for Str and Stringable Sep 13, 2025

Rahul-Mac changed the title ~~feat: add isEmail() for Str and Stringable~~ [12.x] Add isEmail() for Str and Stringable Sep 13, 2025

Rahul-Mac marked this pull request as ready for review September 13, 2025 06:42

taylorotwell reviewed Sep 13, 2025

View reviewed changes

taylorotwell marked this pull request as draft September 13, 2025 12:27

shaedrich reviewed Sep 13, 2025

View reviewed changes

Rahul-Mac added 4 commits September 13, 2025 19:47

feat: use named arguments for better readability

d5e5927

fix: add test for email with emoji, remove values()

bea99d6

feat: add rfc arg

abb10e9

refactor: get the container instance once

21d2cb4

Rahul-Mac marked this pull request as ready for review September 14, 2025 03:01

Rahul-Mac requested review from taylorotwell and shaedrich September 14, 2025 03:01

shaedrich reviewed Sep 14, 2025

View reviewed changes

Rahul-Mac marked this pull request as draft September 15, 2025 01:00

fix: move egulias/email-validator from validation's composer.json to …

280b160

…support's composer.json

Rahul-Mac marked this pull request as ready for review September 15, 2025 01:21

crynobone requested changes Sep 18, 2025

View reviewed changes

taylorotwell closed this Sep 21, 2025

	* @param array<int, int\|string> $parameters
	* @param array<int, int\|'strict'\|'dns'\|'spoof'\|'filter'\|'filter_unicode'\|class-string> $parameters

	"suggest": {
	"illuminate/filesystem": "Required to use the Composer class (^12.0).",
	"laravel/serializable-closure": "Required to use the once function (^1.3\|^2.0).",
	"league/commonmark": "Required to use Str::markdown() and Stringable::markdown() (^2.7).",
	"league/uri": "Required to use the Uri class (^7.5.1).",
	"ramsey/uuid": "Required to use Str::uuid() (^4.7).",
	"symfony/process": "Required to use the Composer class (^7.2).",
	"symfony/uid": "Required to use Str::ulid() (^7.2).",
	"symfony/var-dumper": "Required to use the dd function (^7.2).",
	"vlucas/phpdotenv": "Required to use the Env class and env helper (^5.6.1)."
	},

[12.x] Add isEmail() for Str and Stringable #57049

[12.x] Add isEmail() for Str and Stringable #57049

Conversation

Rahul-Mac commented Sep 13, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Signature

Usage

Basic

Validation Mode

Stringable class

Uh oh!

rodrigopedra commented Sep 13, 2025

Uh oh!

Rahul-Mac commented Sep 13, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

shaedrich Sep 13, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

shaedrich left a comment

Choose a reason for hiding this comment

Uh oh!

rodrigopedra commented Sep 14, 2025

Uh oh!

NickSdot commented Sep 15, 2025

Uh oh!

Rahul-Mac commented Sep 16, 2025

Uh oh!

NickSdot commented Sep 16, 2025

Uh oh!

shaedrich commented Sep 16, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

NickSdot commented Sep 16, 2025

Uh oh!

Rahul-Mac commented Sep 16, 2025

Uh oh!

NickSdot commented Sep 16, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

shaedrich commented Sep 16, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

taylorotwell commented Sep 21, 2025

Uh oh!

Uh oh!

[12.x] Add `isEmail()` for `Str` and `Stringable` #57049

[12.x] Add `isEmail()` for `Str` and `Stringable` #57049

Rahul-Mac commented Sep 13, 2025 •

edited

Loading

`Stringable` class

shaedrich Sep 13, 2025 •

edited

Loading

shaedrich commented Sep 16, 2025 •

edited

Loading

NickSdot commented Sep 16, 2025 •

edited

Loading