Fixes strict-component-boundaries

[cartogram]

This PR resolves false positives with strict-component-boundaries that were introduced with #140.

Fixes #156 #122 and #123

Problem:

The check for whether there is a component in the path was returning true if the path to a module included a pascal case word. In #140 this check changed from the ImportDeclaration source to the full path to the module on the users computer. Since Shopify is a pascal case word and in most cases there is at least one pascal case word in the full path as in Users/your-username/path, this was returning true in almost every ImportDeclaration.

Fix:

The solution was to check the import source for the component in path check rather than the full path to the module source.

🎩 Instructions:

1. Pull this branch
2. Install yalc: yarn add yalc -g
3. run yalc publish
4. cd into a project that is currently reporting false positives for this rule (such as shopify/images)
5. install this branch using yalc: yalc add eslint-plugin-shopify
6. confirm that the false positives are no longer invalid

[BPScott]

I'm not going to pretend to know what this is doing under the hood but adding a bunch of examples to a test suite would make me feel better about it working

[cartogram]

@BPScott thanks for pointing that out. I added what would be a test for this fix. However, this new test is pulling from a fixture folder and we are already ignoring when fixtures is in the path so the test will already never fail.

I am going to need to go back and rework the fixtures ignore and update this PR. Changing the title to WIP in the mean time.

[cartogram]

Updates:

1. solved fixture import so the added test is legit (it will fail without these changes)
2. successful 🎩 in shopify/images and polaris-react

[lemonmade]

I feel like you are not testing the main thing you indicated this PR was to address

[lemonmade]

In my opinion, this is not the most useful way to fix this issue. I would rather you never reference the image source, and instead operate on the relative source from the root of the app. Otherwise, I don’t think you’ll ever be able to get this to actually reflect what we want to enforce

[cartogram]

cc @GoodForOneFare with regards to #122

[cartogram]

Update:

• This rule now operates only on the full relative source. There are fewer edge cases when doing it this way.
• This meant adding a "filename" property to each test that resolves to an actual fixture file. Without this, the resolvedSource would return undefined/missing.
• I also updated the error message to be less vague. strict-component-boundaries error message is vague #122

[BPScott]

Nice, working on absolute paths feels like it protects against false-positives when people do odd things with convoluted relative paths (e.g this should now consistently pass both examples).

Can we add an extra three test cases:

• when a component imports a sibling component using a not the simplest relative path
• when a component's subcomponents import a sibling subcomponent
• when a subcomponent imports its parent's SCSS

The following tests should all pass:

{
  code: `import {someThing} from '../../components/Bar';`,
  parserOptions,
  filename: fixtureFile('basic-app/app/components/Foo/index.js'),
},
{
  code: `import {someThing} from '../Baz';`,
  parserOptions,
  filename: fixtureFile('basic-app/app/components/Foo/components/Bar/index.js'),
},
{
  code: `import {someThing} from '../../Foo.scss';`,
  parserOptions,
  filename: fixtureFile('basic-app/app/components/Foo/components/Bar/index.js'),
}

[cartogram]

@BPScott updated with the tests you posted.