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
This one is similar to #1678 I think, but I'm interested in making this an error for no-extraneous-dependencies
importtype{MyType}from 'my-missing-dep`
the situation where this comes up for me is in a monorepo with yarn workspaces, specifically for internal dependencies, but I guess I don't see why it needs to be limited to those. I have scenarios where I build some packages but not others, and that is determined by the package.json dependency tree. I tested in my project and I can get a missing package.json dependency to still build for a type import, which is where a lint rule would come in handy
Here's an example. If package A imports from package B, but forgets to mark it as a dependency in package.json, normally specifying that I want to build B won't build A either, so this wouldn't need a lint rule because it'd break. But if A happens to get built for another reason (it was already built and never deleted, or package C is also being built, which specifies a dep on A), it could mask the build/runtime error that I would get for missing the dependency. That's where the lint rule would come into play by making it clear at build time when I am missing the dependency.
This applies to types as well regular imports, so I think having an option to enable the check for those would be useful. I'm not 100% sure why it would make sense to ever disable TBH, so I kind of feel like it should be on by default, or not even an option, but that can be a separate question since I know it's a breaking change.
Thoughts?
The text was updated successfully, but these errors were encountered:
This one is similar to #1678 I think, but I'm interested in making this an error for no-extraneous-dependencies
the situation where this comes up for me is in a monorepo with yarn workspaces, specifically for internal dependencies, but I guess I don't see why it needs to be limited to those. I have scenarios where I build some packages but not others, and that is determined by the package.json dependency tree. I tested in my project and I can get a missing package.json dependency to still build for a type import, which is where a lint rule would come in handy
Here's an example. If package A imports from package B, but forgets to mark it as a dependency in package.json, normally specifying that I want to build B won't build A either, so this wouldn't need a lint rule because it'd break. But if A happens to get built for another reason (it was already built and never deleted, or package C is also being built, which specifies a dep on A), it could mask the build/runtime error that I would get for missing the dependency. That's where the lint rule would come into play by making it clear at build time when I am missing the dependency.
This applies to types as well regular imports, so I think having an option to enable the check for those would be useful. I'm not 100% sure why it would make sense to ever disable TBH, so I kind of feel like it should be on by default, or not even an option, but that can be a separate question since I know it's a breaking change.
Thoughts?
The text was updated successfully, but these errors were encountered: