WIP: Cleanup bad aliases and resolve config (fix #513)

[LinusBorg]

• remove /src from resolve:module
• change aliases to prevent mixup with npm modules.
• update alias usage in source files.
• update alias usage in test files.
• test it.

[squirmy]

@LinusBorg

using the @ in the alias makes the import statements look they are importing a scoped module.
https://docs.npmjs.com/misc/scope

i picked this up because I tried it with the airbnb linted which complained they were an extraneous dependency.

perhaps it would be better to use a different character :)

dismissing because of squirmy's valid concern

[LinusBorg]

@squirmy Oh, that's a valid concern of course. Suggestions for a better character?

Will have to try out $ or #

[simplesmiler]

How about '@': resolve('src')? It will be '@/src' in the code, which is just one symbol more then '@src', and is distinguishable from the scoped modules.

[limichange]

How about ~ ? Like nuxtjs.

[LinusBorg]

Doesnt that conflict with asset paths in css-loader?

[limichange]

All thing is fine.
like this.

  import api from '~api'
  import avatar from '~components/avatar'

[LinusBorg]

I mean, in cssl loader, ~ is a special charater to make css-loader aware that the asset path is a node_module path:

from the README:

To be compatible with existing css files (if not in CSS Module mode):

* `url(image.png) => require("./image.png")`
* `url(~module/image.png) => require("module/image.png")`

[LinusBorg]

I think @simplesmiler 's suggestion is probably the best.

[squirmy]

Here's some prior art:
https://github.com/entwicklerstube/babel-plugin-root-import

[LinusBorg]

@squirmy Thanks! that would have thje added benefit of eslint support. Or would the eslint plugin also work without the babel one?

Will have a testrun with it!

[squirmy]

@LinusBorg I think eslint is already happy with the current webpack alias solution. I believe this part of the config is making it work:

  'settings': {
    'import/resolver': {
      'webpack': {
        'config': 'build/webpack.base.conf.js'
      }
    }

Was more hinting at the fact that others have done the same concept as above and used @/ as the 'alias'.

I think @simplesmiler's suggestion would work well. It requires one alias, and things would be referenced like:

@/file-at-root
@/components/file
@/assets/file

Any other aliases for further down the tree can be added by the user. :-)

[LinusBorg]

Ok then, I think that's good enough for me, will use @ -> /src

[LinusBorg]

Sorry that this is still unfinished, had a busy week. Hope to finish this in a quiet minute in the next days.

[LinusBorg]

Changed to @, but not tested locally yet.

[LinusBorg]

Finally came around to testing this.

[dfdgsdfg]

Seems ~assets alias not working with the latest template. Is this realate with this?

Also @/assets does not work.

<-- NOTE: Not work -->
<img src="~assets/img.png">
<img src="@/assets/img.png">

asset resolving rules doc

[LinusBorg]

~@/assets/img.png

[LinusBorg]

We should probably adjust the docs a little to reflect that, even though the included aliases where never thoroughly documented in the first place.

[dfdgsdfg]

@LinusBorg Thanks. 👍
~@/assets/img.png just works fine.

[AlexandreBonaventure]

@LinusBorg
Checkout: https://www.npmjs.com/docs/orgs/?utm_campaign=2017-03-22%20free%20Orgs&utm_medium=email&utm_source=Eloqua
From now on, npm allows free orgs, we should see more and more the use scope (eg. @org/packgage)
It will then enter in conflict with the actual alias @

[LinusBorg]

No, it won't. The alias woeks on paths like @/components, not @components.

[AlexandreBonaventure]

OK, but maybe for the sake of readability (could be misleading for beginners), we should find another symbol. Just saying... Could provide a PR if accepted

[LinusBorg]

We're open to suggestions. As you can see in the previous comments on this PR, we discussed a few.

[AlexandreBonaventure]

My bad, I noticed the subject was brought to the table before. But still I found the @ a bit misleading. Why not & or # as you suggested in the first place ?