Import from project root

An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20180328/c9321f39/attachment-0001.html>

Invalid mailing list, you should fill issue in Node.js repository.
https://github.com/nodejs/node/issues

On Wed, Mar 28, 2018 at 7:18 PM, Sebastian Malton <sebastian at malton.name>
wrote:

> With really big projects I find it is useful to do the following (it is in
> node but the sentiment is still there)
>
>
> ```
> global.rootRequire = function (path) {
>     require(require('path').resolve(__dirname, path));
> }
> ```
>
> As moving towards import/export is a good thing I was wondering if this
> would be possible?
>
> Question: how to show that this is wanted?
> Question: how do we say what the root is?
>
>
> For question 1 it could be just the last thing that is searched or use
> import.root
>
> For question 2 that could be a config something or root is based on the
> first file ran
>
> Sebastian Malton
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20180329/a1509e53/attachment.html>

An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20180329/05f7c7a9/attachment.html>

On Thu, Mar 29, 2018 at 2:49 PM, Sebastian Malton <sebastian at malton.name>
wrote:
>
> No because this is something that I am proposing as an extension
> to es import/export

The *ModuleSpecifier* string of `import` is entirely environment-specific,
not covered by the ECMAScript standard at all. From [Runtime Semantics:
HostResolveImportedModule ( referencingModule, specifier )][1]:

> HostResolveImportedModule is an **implementation-defined abstract
> operation** that provides the concrete Module Record subclass
> instance that corresponds to the ModuleSpecifier String,
> specifier, occurring within the context of the module represented
> by the Module Record referencingModule.

Instead of the ECMAScript spec definining it, it's left to environments to
define it appropriately for the environment, since different environments
have different design constraints and criteria. For instance, [this part of
the WHAT-WG HTML spec][2] covers using modules on the web (drawing on
various underlying initiatives such as [`import()`][3] and
[`import.meta`][4]). (In this initial version, unsurprisingly, module
specifiers are essentially URLs, with the requirement [for now] that
relative URLs must start with `/`, `./`, or `../` so that "bare" relative
URLs can be given meaning down-the-line.)

So if you want a special token for "root," that will be an
environment-specific request, not something for TC39.

Of course, TC39 could define some syntax (outside the *ModuleSpecifier*)
that says "work from the root" while still leaving it up to the environment
what "the root" is, but there's no particular reason to do that rather than
leaving it to environments to handle as part of the *ModuleSpecifier*.

-- T.J. Crowder

[1]: https://tc39.github.io/ecma262/#sec-hostresolveimportedmodule
[2]:
https://html.spec.whatwg.org/#integration-with-the-javascript-module-system
[3]: https://tc39.github.io/proposal-dynamic-import/
[4]: https://tc39.github.io/proposal-import-meta/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20180329/542c3947/attachment-0001.html>

`global.rootRequire` is quite bad (like user-added globals in general), I'd
just do that https://gist.github.com/branneman/8048520#gistcomment-2247189,
or use lerna, or use webpack resolvers

2018-03-29 17:37 GMT+02:00 T.J. Crowder <tj.crowder at farsightsoftware.com>:

> On Thu, Mar 29, 2018 at 2:49 PM, Sebastian Malton <sebastian at malton.name>
> wrote:
> >
> > No because this is something that I am proposing as an extension
> > to es import/export
>
> The *ModuleSpecifier* string of `import` is entirely environment-specific,
> not covered by the ECMAScript standard at all. From [Runtime Semantics:
> HostResolveImportedModule ( referencingModule, specifier )][1]:
>
> > HostResolveImportedModule is an **implementation-defined abstract
> > operation** that provides the concrete Module Record subclass
> > instance that corresponds to the ModuleSpecifier String,
> > specifier, occurring within the context of the module represented
> > by the Module Record referencingModule.
>
> Instead of the ECMAScript spec definining it, it's left to environments to
> define it appropriately for the environment, since different environments
> have different design constraints and criteria. For instance, [this part of
> the WHAT-WG HTML spec][2] covers using modules on the web (drawing on
> various underlying initiatives such as [`import()`][3] and
> [`import.meta`][4]). (In this initial version, unsurprisingly, module
> specifiers are essentially URLs, with the requirement [for now] that
> relative URLs must start with `/`, `./`, or `../` so that "bare" relative
> URLs can be given meaning down-the-line.)
>
> So if you want a special token for "root," that will be an
> environment-specific request, not something for TC39.
>
> Of course, TC39 could define some syntax (outside the *ModuleSpecifier*)
> that says "work from the root" while still leaving it up to the environment
> what "the root" is, but there's no particular reason to do that rather than
> leaving it to environments to handle as part of the *ModuleSpecifier*.
>
> -- T.J. Crowder
>
> [1]: https://tc39.github.io/ecma262/#sec-hostresolveimportedmodule
> [2]: https://html.spec.whatwg.org/#integration-with-the-javascrip
> t-module-system
> [3]: https://tc39.github.io/proposal-dynamic-import/
> [4]: https://tc39.github.io/proposal-import-meta/
>
>
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20180404/27f2210c/attachment.html>