Add all root project env files to ImportantFiles

[haidubogdan]

Closes #9229

• add all root project env files to ImportantFiles
• additional coloring lexer fix for single quoted string with slash
• remove envFileResolver service and replace it with a mime-resolver.xml to handle mime file association
• all files containing .env. in their name are associated with text/x-env mimetype

Coloring fix for single quoted string

There was a escape done on slash inside strings, which created a small coloring issue.

Before:

After:

File association

Before:
.env.test and .env.local.demo were not under env mime type

After:

---

^Add meaningful description above

Click to collapse/expand PR instructions

By opening a pull request you confirm that, unless explicitly stated otherwise, the changes -

• are all your own work, and you have the right to contribute them.
• are contributed solely under the terms and conditions of the Apache License 2.0 (see section 5 of the license for more information).

Please make sure (eg. git log) that all commits have a valid name and email address for you in the Author field.

If you're a first time contributor, see the Contributing guidelines for more information.

If you're a committer, please label the PR before pressing "Create pull request" so that the right test jobs can run.

PR approval and merge checklist:

1. Was this PR correctly labeled, did the right tests run? When did they run?
2. Is this PR squashed?
3. Are author name / email address correct? Are co-authors correctly listed? Do the commit messages need updates?
4. Does the PR title and description still fit after the Nth iteration? Is the description sufficient to appear in the release notes?

If this PR targets the delivery branch: don't merge. (full wiki article)

[haidubogdan]

@mbien @matthiasblaesing

Just checking if the mime update is too extensive, and if it's ok for you to have all env files under ImportantFiles for web projects.

[mbien]

looks good to me but I have limited experience regarding php.

maybe @matthiasblaesing could take a quick look

[matthiasblaesing]

The matching is too broad. For example "test.env.js" or "test.env.ini" will also be matched and instead of being correctly handled as their correct mimetype env will occupy them.

I think it would be good to split the two different problems into different PRs. The change to the grammar makes sense to me. The broad mime type squatting does not.

[matthiasblaesing]

Shouldn't this be covered by resources/mime-resolver.xml?

[haidubogdan]

Thank you @matthiasblaesing .
I agree, the mime association can be a different PR.
I will have a second look to see if matching ".env." is enough for various frameworks.
But this might require double MIME registration to fix the ".test" mime type association.

[matthiasblaesing]

I will have a second look to see if matching ".env." is enough for various frameworks. But this might require double MIME registration to fix the ".test" mime type association.

Not sure that I get what you mean. test.env.js was just an illustation. The file could also be siteA.env.js, staging.env.js and so on. The filetype could also be .ts (I'm aware of the convention to call the file environment.ts in angular, but they could also be named staging.env.ts, .java or any other filetype.

The problem with .env files from my POV is, that they are an ad-hoc solution combined with a bad naming convention. From my POV it would much more sense to call the shown .env files dev.env dist.env and local.env. That way the OS won't hide the sample files and filetype matching is trivial.

What might be acceptable for the substring matcher would be to move the mimetype mapping far down and let it be considered last/late. That might need adjustment to other modules (the LSP integrations currently have a very high position, so this might need to be lowered).

[haidubogdan]

The existing MimeResolver service implemented in EnvFileResolver will not change the already associated mime type.
So, js, ini ... files will not be modified with the env mime type.
But I think the current implementation should be changed ... so basically any file which starts with ".env." can be associated with the env mime type. Technically it can be considered dot file.

My issue was with ".test" file extensions, I noticed that there are Symfony php Projects which use .env.test to specify a env file used for testing.
Overwriting this mime type can be done only with the custom mime_resolver.xml registration. But it's a nitpick.
And then it's a matter of excluding netbeans generated files :) . (.lexer, .error) .

I agree it is a bad naming convention, a bit confusing to find a pattern, but maybe we can find a balanced solution that can work for most of the IDE users.