I think Brunch does this, if I recall correctly.
This is an important feature because people often misunderstand that transitive dependencies aren鈥檛 supposed to be importable.
See https://github.com/facebookincubator/create-react-app/issues/1714 and https://github.com/facebookincubator/create-react-app/issues/1622 for examples.
eslint-plugin-node has similar rules for this:
eslint-plugin-import also has a rule which could help to hint developers about importing transitive dependencies.
@jokeyrhyme I don't think these are similar. The rules you link to protect against importing a non-existing file (which would break the build anyway). But I'm talking about a file that exists but comes from a transitive dependency.
@matoilic This one looks right. Want to send a PR adding it?
One potential issue here is I don't think editing package.json would trigger an eslint-loader recheck, so the user would be stuck with a misleading message in our setup.
@gaearon Sure, I can work out a PR. What do you think about importing dev dependencies? Should there be a warning / error when importing a dev dependency, especially in a production build?
I'm not sure on how to trigger a recheck or rebuild when editing package.json. Could a Webpack plugin be a solution? I haven't come across one which does something like that. We might need to create one to solve the issue.
What would you think about implementing this upstream in webpack? This seems like it'd be super helpful for all / most projects, not only React projects / projects using that ESLint plugin.
Could a Webpack plugin be a solution?
That may be the case. I鈥檓 not sure.
What would you think about implementing this upstream in webpack?
It may be better longer term but if we can prototype this feature here and figure out the edge cases sooner, that might work out just as well. IMO plugins like this end up good when they start in userland, and if proven useful, move into the core.
Another good point: https://twitter.com/_jayphelps/status/838489432801959936
I think this is important enough to not tag as a future idea and instead for 0.10. 馃槃
Sounds good. I鈥檓 not sure I鈥檓 aware of a good way to make it happen tho.
Oops 馃槉
I was thinking of these rules but navigated to the wrong ones in my haste
https://github.com/mysticatea/eslint-plugin-node/blob/master/docs/rules/no-unpublished-require.md
https://github.com/mysticatea/eslint-plugin-node/blob/master/docs/rules/no-unpublished-import.md
Measure twice, cut once :D
I think those two rules are more intended for package creators. When you install react-scripts the NPM registry will only contain "published" files and thus only files which already pass the check. That's how I understand it. But those rules might be useful to solve #1720.
Pushing back to 0.11.
Any news ?
@matoilic
This would be a great addition for junior engineers who don't understand the reason their import works is due to hoisting and/or node_modules flattening
In the meantime, I'm setting up depcheck
This issue has been automatically marked as stale because it has not had any recent activity. It will be closed in 5 days if no further activity occurs.
This issue has been automatically closed because it has not had any recent activity. If you have a question or comment, please open a new issue.
Most helpful comment
eslint-plugin-import also has a rule which could help to hint developers about importing transitive dependencies.