wbern
commented
3 years ago I think this would make a great eslint plugin, possibly under this plugin? https://github.com/benmosher/eslint-plugin-import
I tried to make it work specifically using this rule once, but it didn't quite work out for me. https://github.com/benmosher/eslint-plugin-import/blob/master/docs/rules/no-relative-parent-imports.md
Maybe this rule could work better..? https://github.com/benmosher/eslint-plugin-import/blob/master/docs/rules/no-internal-modules.md
In rush world, perhaps something more simple could be made out of a small script that either naively looks for ../'s, or move the entire project to a tmp/ directory? Or perhaps the import resolver in the eslint plugin could be extracted and made for some performant rush-specific check?
dmichon-msft
Summary
One concern with many monorepo setups is keeping each of the individual projects separate.
It is possible for developers to import source files directly from other projects.
We have a large project and it would be great if the monorepo tools could enforce fencing around projects to stop developers accidentally (or purposefully) bypassing dependencies and linking to source files directly.
The worry is that informal dependencies can be created between projects as well as circular dependencies.
Is this something that might fit nicely in Rush Stack? Could it be incorporated somehow into the stack of tools?
Repro steps
Step 1:
Create 2 npm modules in your monorepo
Step 2:
Attempt to import files from one npm module to the other directly via relative paths.
Eg:
import {ThingINeed} from "../../../../../../totally/different/project/ThingINeed";
Expected result:
This action should not be allowed.
Actual result:
Both projects compile fine and with no errors.
Details
Perhaps this could be handled via linting somehow? This way we'd get nice squiggles under the import.
Standard questions
Please answer these questions to help us investigate your issue more quickly:
node -v)?