You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
With this setup, e.g. @some/name/foo maps to some/path/foo/src.
I've seen that sheriff already has support, when the wildcard is at the end. But I could not get it working with the wildcard in the middle of the path.
Otherwise the plugin looks very promising, because we are looking for some linter rule to prevent to import from another entry point with a relative path instead of using the name.
The text was updated successfully, but these errors were encountered:
Hey Raphael, wow! I was not aware that one can have these kinds of paths. I guess, there could also be the possibility for something like some/path/**/src or even some/path/*/src/*lib.
I will take a look into it. There are special unit tests for the matching algorithm. So it should hopefully not take too much time.
We have a setup where we make heavy use of secondary entry points with ng-packagr. In
tsconfig.json
we make use of the following:With this setup, e.g.
@some/name/foo
maps tosome/path/foo/src
.I've seen that sheriff already has support, when the wildcard is at the end. But I could not get it working with the wildcard in the middle of the path.
Otherwise the plugin looks very promising, because we are looking for some linter rule to prevent to import from another entry point with a relative path instead of using the name.
The text was updated successfully, but these errors were encountered: