<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

<html xmlns="http://www.w3.org/1999/xhtml"><head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
 </head><body><p>Currently there isn't a way to import a module using an app root module specifier.</p><p><br></p><p>I.E. `import * as Stuff from 'utils/someUtil.js'`</p><p><br></p><p>Relative paths suffices in the simplest applications but not being able to resolve from the root of the app leads to a complex stack of relative path entries I.E. `../../..`</p><p><br></p><p>One example of where these complex stacks arise is importing source modules from within test modules where usually tests are defined in a test folder separated from the source.</p><p><br></p><p>Another issue arises when moving a file to another location which then leads to recalculating the relative path stack.</p><p><br></p><p>One idea I have is that each host has a default URL protocol. For now I will call it **moduleSpecifierDefaultProtocol** that will resolve double front slashes `//` to the default protocol</p><p><br></p><p>In a browser the default protocol already gets resolved and is based on the URL of the document requested.  I.E.  '//utils/someUtil.js` resolves to `https://utils/someUtil.js` when `https` is the protocol used in the requesting  document</p><p><br></p><p>Hosts like NodeJS could interpret '**moduleSpecifierDefaultProtocol** to be the root of the app allowing `import * as Stuff from '//utils/someUtil.js'`.</p><p><br></p><p>The other idea I have (and probably needs to be a separate but related solution proposal) is to have custom alias mappings which would be defined in a place where the host can find and resolve module specifier aliases I.E. an `.es` file in the app root containing a json map of aliases. The maps could possibly be auto generated using build tools when publishing an app.</p></body></html>