(these import statements will work from within any .js file within your project)

So, essentially, ~/ and myhub/ point to myhub/src/ on the filesystem because that is how you set things up in your package.json using the system.directories.lib config. If, for instance, you changed system.directories.lib to src/mylibbylib then your import statements would have to become:

The directory myhub/src/mylibbylib would become the new main root for import because you’re sepcifying “name of your app” (myhub) points to here. In this case you would lose some flexibility as everything would have to be inside mylibbylib now, at least to maintain sane imports.

Another (final) example would be if you renamed src/ to blah/. You would need to update package.json, because now StealJS doesn’t know where to look when encountering an import statement that starts with the name of your package (myhub):

"directories": {
"lib": "blah"
}

Once you did this, you would not have to change your import statements; the following would continue to work:

Because you updated the package.json to tell StealJS about the new main root location for imports.

Not sure if that helps at all.

Edit:

Additionally, regarding your question:

Will this path structure work for both import and the paths option?

It is my understanding that paths for the system.paths option in package.json must be actual paths, and wildcard expansion of things like ~ and myhub (or whatever is the name of your app) will not work here.

Looking at the docs, it looks like it actually may be possible to do what you want.

Yes, it’s possible, but you can only use a mask with a two-part module name. Something like libs/*. So you can’t make localisation and somethingelse both hit the same path unless everything else does. However you can make libs/localisation and libs/somethingelse get mapped to a particular location.