Import from project root

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Import from project root

Sebastian Malton
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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Import from project root

Michał Wadas
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 <[hidden email]> 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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Import from project root

Sebastian Malton
No because this is something that I am proposing as an extension to es import/export

Sebastian Malton

Sent: March 29, 2018 9:45 AM
Subject: Re: Import from project root

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 <[hidden email]> 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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Import from project root

T.J. Crowder-2
On Thu, Mar 29, 2018 at 2:49 PM, Sebastian Malton <[hidden email]> 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




_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Import from project root

Cyril Auburtin
`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 <[hidden email]>:
On Thu, Mar 29, 2018 at 2:49 PM, Sebastian Malton <[hidden email]> 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




_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss