-
Notifications
You must be signed in to change notification settings - Fork 134
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
Disable namespace provider for Packages and subfolder #1677
Conversation
There's no agreed standard for namespaces or folder layouts, which makes this tricky. We disable it for It doesn't work for this example, but it does work for the scenario of taking one of Unity's own packages and copying it from On the other hand, the assembly defined in I don't think we can get this right 100% of the time, but we can set up a good default, and I think removing the folder location and the package name is a good start. If the name of the root folder of the actual assembly is the required root namespace ( |
And that's made me think that if we generate projects for all packages, we should take a look at what happens for packages in |
I've excluded |
This handles the edge case of a git repo in the Packages folder that does not have a package in the repo root folder
Thanks for this set of changes; I think this is an improvement. |
Add new rules to disable the "namespace provider" for the following folders. This will stop Rider/ReSharper from suggesting that folder as part of the namespace name. Once this PR is applied, the following folders will no longer be included in namespace name suggestions:
Assets
Assets/Scripts
Packages/<package-root>
- any top level folder underPackages
Packages/<package-root>/**
- any non-project folders. I.e. any folder under a package root that does not havepackage.json
Packages/<package-root>/**/Runtime
Packages/<package-root>/**/Scripts
Packages/<package-root>/**/Runtime/Scripts
Packages/<package-root>/**/Scripts/Runtime
Library/PackageCache/<package-root>
Library/PackageCache/<package-root>/**
- any non-project folders. I.e. any folder under a package root that does not havepackage.json
Library/PackageCache/<package-root>/**/Runtime
Library/PackageCache/<package-root>/**/Scripts
Library/PackageCache/<package-root>/**/Runtime/Scripts
Library/PackageCache/<package-root>/**/Scripts/Runtime
This means that code in packages do not get the package name suggested, nor
Scripts
,Runtime
, or a combination of the two. The patterns will also exclude any folder at the root of a package folder that does not containpackage.json
. This matches the use case of a git repo added to thePackages
folder that does not have a package in the root folder of the repo (the package must be manually added via afile:
reference inPackages/manifest.json
)The
Library/PackageCache
patterns stop ReSharper/Rider prompting if the user generates projects for referenced packages (which is arguably a bad idea, as these files should not be user editable, and are not in source control).This does not fix all incorrect warnings for mismatched namespaces, as there are no widely accepted standards or conventions for namespaces or folder structure, but it does remove a number of poor suggestions.
It is not currently possible to set a root namespace for packages (although this will be fixed in Unity 2020.2), so it is hard to get correct suggestions. The current recommendation is that the root folder of the assembly (not the package) has the same name as the root namespace. E.g.
Packages/[email protected]/Unity.Collections/UnityCollections.asmdef
would have a root namespace ofUnity.Collections
. These changes support this scheme.Fixes #1161 and addresses #1584 and RIDER-36546