Using webpack aliases in simorgh

[oluoluoxenfree]

Resolves #2567

Overall change:

Uses webpack directory aliasing previously set up in #3318

Code changes:

• A bullet point list of key code changes that have been made.
• When describing code changes, try to communicate how and why you implemented something a specific way, not just what has changed.

---

• I have assigned myself to this PR and the corresponding issues
• Automated (jest and/or cypress) tests added (for new features) or updated (for existing features)
• This PR requires manual testing

[benjaminhobbs]

Found those in storybook and cypress need reverting, they don't share the same webpack setup so cannot use these aliases at all

[benjaminhobbs]

FYI @hindsc52 @dr3

Ok so problems in order:

1. At first glance this looks pretty good. But the build passes when it absolutely shouldn't! Storybook won't run, the only e2es that still run are those missed in the PR (cypress/integration/application/index.js)
2. Some files are missed as proved by some e2es still working in point 1
3. Some files changed use app when they could directly use lib. I fixed a couple and later realised I missed some more, but this doesn't really matter because...
4. This approach cannot work at all. The webpack config is for our app, the webpack config is not shared in cypress, 3rdPartyCypress or storybook - so every single alias reference in there fails - without erroring the build. This is the cause of point 1. We cannot even remove change to storybook because the story files themselves have aliases that it cannot understand. If we reverted these back them I'm not certain the components themselves could render because it'll still try to render those components in storybook with the unresolvable aliases. So we'd then have to not use aliases in components/containers or we'd have to extend the webpack config to work for storybook. But is another setup task to be done before this.

Is all this worth the aliases? I thought this'd be easy when I wrote the issue. I'm tempted to revert the addition of aliases and not do this at all.

Horrifying that such an innocuous seeming PR can cause a confusing thing as a passing build with nearly everything outside the main app failing.

PS how can we avoid all tests not running and the build still passing in future PRs? That seems much more important to fix that anything we're trying to do here.

PPS @oluoluoxenfree don't let this get you down, we all missed the dragons herein when we approved the preparatory PR - maybe Chris or Drew have a quickfix, but I can't think of one.

[oluoluoxenfree]

@benjaminhobbs can we not do something like this?

storybookjs/storybook#3339

[thekp]

I am closing this PR, to continue it here : #3707