On Thu, Jul 3, 2014 at 9:05 PM, Brendan Eich bren...@mozilla.org wrote:
Jussi Kalliokoski wrote:
So sometimes someone can need it, so we must have good support? Is that
how we operate these days?
Cool down a minute :-|.
Heh, the internet is a funny place when it comes to interpreting
On Fri, Jul 4, 2014 at 10:19 AM, Jussi Kalliokoski
jussi.kallioko...@gmail.com wrote:
On Thu, Jul 3, 2014 at 9:05 PM, Brendan Eich bren...@mozilla.org wrote:
Cool down a minute :-|.
I now realize that my tone on this thread hasn't been very considerate, and
apologize if I offended anyone,
On Thu, Jul 3, 2014 at 1:29 AM, Brian Di Palma off...@gmail.com wrote:
The arguments for and against supporting cyclic dependencies seem to be
academic. I'm yet to see any evidence of their importance in practice nor
proof they they are fundamental ... or not.
Transitive cyclic
So sometimes someone can need it, so we must have good support? Is that how
we operate these days?
Imagine a large codebase which already has transitive cyclic dependencies.
If the module system has poor support for them it might still work
with them until one day a developer reordered the
On Thu, Jul 3, 2014 at 11:41 AM, Brian Di Palma off...@gmail.com wrote:
So sometimes someone can need it, so we must have good support? Is that
how we operate these days?
Imagine a large codebase which already has transitive cyclic dependencies.
If the module system has poor support for
On Thu, Jul 3, 2014 at 2:31 AM, Jussi Kalliokoski
jussi.kallioko...@gmail.com wrote:
Tools like Traceur can support it for an easier migration path since they
already have diverged from ES.next anyway with all the annotations (for
which, off topic, I haven't seen even a proposal here yet)
On Thu, Jul 3, 2014 at 5:42 PM, John Barton johnjbar...@google.com wrote:
On Thu, Jul 3, 2014 at 2:31 AM, Jussi Kalliokoski
jussi.kallioko...@gmail.com wrote:
Tools like Traceur can support it for an easier migration path since
they already have diverged from ES.next anyway with all the
On Tue, Jul 1, 2014 at 10:28 PM, Kevin Smith zenpars...@gmail.com wrote:
As such, we are balancing the marginal user experience gains of
export-overwriting against the better support for circular dependencies
of real modules.
Another way of looking at it:
Being in control of the
But it's neither simple nor solid. It's overtly complicated to support
features that shouldn't be there.
I have to disagree here. If we drop default imports, then we can describe
the module system like this:
Variables can be exported by name. Variables can be imported by name.
It doesn't
circular dependencies in CJS are much easer then that
https://gist.github.com/calvinmetcalf/57be20b8eda0ee8fe6de
On Wed, Jul 2, 2014 at 4:09 AM, Jussi Kalliokoski
jussi.kallioko...@gmail.com wrote:
On Tue, Jul 1, 2014 at 10:28 PM, Kevin Smith zenpars...@gmail.com wrote:
As such, we are
circular dependencies in CJS are much easer then that
https://gist.github.com/calvinmetcalf/57be20b8eda0ee8fe6de
Umm... I would rather call that tricky as hell ; )
___
es-discuss mailing list
es-discuss@mozilla.org
circular dependencies in CJS are much easer then that
https://gist.github.com/calvinmetcalf/57be20b8eda0ee8fe6de
Umm... I would rather call that tricky as hell ; )
Besides, it fails if you do `require(./b)`, IIUC.
___
es-discuss mailing list
I agree with everything Jussi wrote. He gets to the heart of the issue.
The points that have been previously made about bundling modules also
apply to REPLs. If a module must be in a file, I can't easily define
modules at a REPL prompt.
--scott
___
The arguments for and against supporting cyclic dependencies seem to be
academic. I'm yet to see any evidence of their importance in practice nor
proof they they are fundamental ... or not.
I wouldn't say that cyclic dependencies are academic, in the sense of not
real. If they are allowed
On Wed, Jul 2, 2014 at 7:09 PM, John Barton johnjbar...@google.com wrote:
* (Reliably) statically analyzable syntax. This is my favourite feature
and really awesome. Allows engine to fetch next modules while the current
one is still being parsed,
This isn't true -- all module designs in
You can of course assume that the require call with a static string does
what you'd expect but then you might end up loading something that was
never actually required but someone had their own require function there
instead that has something else.
This is a solved problem actually
This seems like a bit too many issues, so let me just correct one
(important) one.
On Wed, Jul 2, 2014 at 2:09 PM, Jussi Kalliokoski
jussi.kallioko...@gmail.com wrote:
On Wed, Jul 2, 2014 at 7:09 PM, John Barton johnjbar...@google.com
wrote:
Now, I know there are people that think that
On Wed, Jul 2, 2014 at 3:38 PM, Kevin Smith zenpars...@gmail.com wrote:
But it's neither simple nor solid. It's overtly complicated to support
features that shouldn't be there.
I have to disagree here. If we drop default imports, then we can describe
the module system like this:
The arguments for and against supporting cyclic dependencies seem to be
academic. I'm yet to see any evidence of their importance in practice nor
proof they they are fundamental ... or not.
Transitive cyclic dependencies. I'd say that's the case that was in
the minds of the authors of the
On Wed, Jul 2, 2014 at 3:29 PM, Brian Di Palma off...@gmail.com wrote:
The arguments for and against supporting cyclic dependencies seem to be
academic. I'm yet to see any evidence of their importance in practice nor
proof they they are fundamental ... or not.
Support for them is needed,
So I think we've gone over the interoperability argument already. That is,
with default exports (or module-object-overwriting), you can write
something like this:
import x from some-old-module;
Without default exports, you'll have to use something like one of the
following:
import {
There are three arguments for default exports:
1. Anonymous exports are a value-adding feature, as it allows the user to
use a library without having to know the export name.
2. Default exports allow more streamlined renaming of the imported binding.
3. Default exports allow smoother
My recommendation is to drop the default export feature and leave
everything else as is (except perhaps for making module.x equivalent to x
per Andreas). Given that the current module system has far better support
for circular dependencies than module-as-module designs, the static
export design
My recommendation is to drop the default export feature and leave
everything else as is (except perhaps for making module.x equivalent to x
per Andreas). Given that the current module system has far better support
for circular dependencies than module-as-module designs, the static
export
If it had good enough support for circular dependencies, would we be able
to make sense of module-as-module designs?
Side note: I meant object-as-module really. It's kinda funny that I
capped off all of that with such a silly mistype. : )
___
one benefit of default exports is forcing people to choose one of
export { x as exports };
export { x as default };
export { x as _ };
this is the one chance to get everyone on the same page
as far as object-as-module having circular dependency issues, can you
elaborate on that, I
On Tue, Jul 1, 2014 at 1:36 PM, Calvin Metcalf calvin.metc...@gmail.com
wrote:
one benefit of default exports is forcing people to choose one of
export { x as exports };
export { x as default };
export { x as _ };
this is the one chance to get everyone on the same page
I
Can't proxies or getters/setters be used to get objects to behave like they
have named exports? As in, when getting a property of the object it looks
up the current value of the bound value in the module. I can't see why this
wouldn't work, but there is probably a reason since nobody has proposed
module name from './path'
...
name.method();
Right - that would work for objects-as-modules, but this wouldn't:
import { something } from ./path;
Unless you somehow emitted getters for all references to something.
Without consulting documentation, I would expect that these
From: es-discuss es-discuss-boun...@mozilla.org on behalf of C. Scott Ananian
ecmascr...@cscott.net
If we're cutting things from the ES6 module spec, can we consider cutting the
magical mutable `import {foo} from ./foo;` bindings as well? Experience
has shown that the rare cases where
If it had good enough support for circular dependencies, would we be able
to make sense of module-as-module designs?
OK, so let's assume for the sake of argument that objects-as-modules is
not confusing, so (4) doesn't apply. All of the arguments for and against
default exports also apply to
As such, we are balancing the marginal user experience gains of
export-overwriting against the better support for circular dependencies
of real modules.
Another way of looking at it:
Being in control of the language, you can always invent new sugar to
optimize user experience (within limits)
On 27 June 2014 21:45, C. Scott Ananian ecmascr...@cscott.net wrote:
On Fri, Jun 27, 2014 at 3:34 PM, Andreas Rossberg rossb...@google.com
wrote:
All this means is that there will effectively be two different module
systems, and in practice, every module provider has to pick one. Which
is a
Let me try to restate my request for clear information on the advantages of
module bindings vs module object architectures.
The import syntax already allows pre-execution tools to collect every
module that will be accessed by a root dependent module (including some
that may not be used). This
On Sun, Jun 29, 2014 at 1:00 PM, Domenic Denicola
dome...@domenicdenicola.com wrote:
On Jun 29, 2014, at 12:50, Rick Waldron waldron.r...@gmail.com wrote:
Static analysis would be necessary if JavaScript ever wanted to make
macros possible in modules. I don't have exact numbers nor have I
On Mon, Jun 30, 2014 at 7:14 AM, Andreas Rossberg rossb...@google.com
wrote:
...this is why I've been arguing strongly for consistent syntax
regardless.
Static checking and lazy binding should be value added features, not
something I have to think about every time I import a module.
On 30 June 2014 19:01, C. Scott Ananian ecmascr...@cscott.net wrote:
On Mon, Jun 30, 2014 at 7:14 AM, Andreas Rossberg rossb...@google.com
wrote:
...this is why I've been arguing strongly for consistent syntax
regardless.
Static checking and lazy binding should be value added features,
It's not just about interoperability. It's also about enabling the pattern
that proved itself to work quite well - module as a function, module as a
class, module as a function with named exports attached in one namespace.
I suppose if that pattern is not explicitly supported it might be just
On Jun 30, 2014 3:59 PM, Karolis Narkevičius karoli...@gmail.com wrote:
In fact, doesn't being able to import things like above make es6 modules
already interoperable with CJS?
Almost, but not quite, since the name of the module itself ($, fs, etc) is
not included in a typical commonjs module.
It's not just about interoperability. It's also about enabling the pattern
that proved itself to work quite well - module as a function, module as a
class, module as a function with named exports attached in one namespace.
But we have to ask why that pattern worked out, and my take is that
Another interoperability issue is circular dependencies, es6 modules have
support for certain kinds that cjs doesn't (like function declarations)
and cjs has support for 2 modules using each others exports (as long as
they arn't single exports).
If it wasn't for this you could load cjs modules
On Mon, Jun 30, 2014 at 12:00 PM, Kevin Smith zenpars...@gmail.com wrote:
What's not clear is the advantage of module bindings form for modules.
When the world of possibilities opens up, what specific things will I see
there?
I think I'm following you now. So let's pose the question like
On Mon, Jun 30, 2014 at 4:32 PM, John Barton johnjbar...@google.com wrote:
Based on other discussion on this point, it seems like
module-as-named-bindings can interoperate with CJS and AMD except perhaps
in some unusual cases. Clarifying these cases would help.
To me, these two lists are
- Mutable bindings
As far as I know, this is not something JS developers understand. What is
it and what makes it an advantage?
Since imported bindings are just aliases for variables over in the
originating module, changing the value of that variable in the exporting
module will change
If there is no module object overwriting, then I suppose it could be
inlined. If you allow overwriting, then you would need the further
restriction that you cannot import from overridden module objects.
Sorry, strike the second sentence. (Trying to do too many things at once!)
I think that a possible compromise that can still make the ES6 module
system more compatible with both AMD and CommonJS modules is by this:
If there are no exports from a module, named or not, make the export
process implementation-defined. If an ES5 Node module uses module.exports,
then Node
Thanks Kevin. I'm going to challenge your list below, but I hope you don't
take it negatively. I want the case for the module system to be as strong
as possible.
On Sat, Jun 28, 2014 at 11:51 AM, Kevin Smith zenpars...@gmail.com wrote:
Static checking of imports and exports has well-known
On Sat, Jun 28, 2014 at 3:58 PM, Kevin Smith zenpars...@gmail.com wrote:
Static checking will be limited anyway. If you want to go this way you
should use typescript.
That's the point that I'm trying to make, shops will choose other
languages that provide more static information. We should
On Jun 29, 2014, at 12:50, Rick Waldron waldron.r...@gmail.com wrote:
Static analysis would be necessary if JavaScript ever wanted to make macros
possible in modules. I don't have exact numbers nor have I done any formal
surveys, but the general response to Sweet.js has been overwhelmingly
CommonJS falls a bit short on the import side because static analysis of
require calls is brittle. A special language syntax would enable a robust
static analysis of dependencies.
If you don't have static exports, then how are you going to know if what
you import is valid? You can't,
Static checking will be limited anyway. If you want to go this way you shoud
use typescript.
If you don't want static checking you should stick with ES3. Fixed that for you.
Yes big projects are possible with JS, I work on them everyday. It
would be nice if the language made them easier,
Bruno and John's arguments are classic examples of the straw man fallacy.
In my concrete examples I made no reference to static type systems (or any
type systems at all, for that matter). I merely pointed out that by
allowing the programmer to provide compile-time information in the form of
I'd be interested in knowing if it's possible that instead of changing
the ModuleImport form the default import/export idea could be
postponed instead.
It can. Just to be clear, that means that we'd have these two forms on the
import side:
module FS from fs;
import { stat } from
: Thu, 26 Jun 2014 10:50:20 -0400
Subject: Re: ModuleImport
Now the author can choose to export more things later without making
breaking changes to the module. The only downside to this is the
(apparently mandatory) curly braces around the imported object. If single
export/import becomes
I fully admit that I'm probably hanging a little behind in terms of emails
because I get them bundled into 4-5 each.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Why make things so complex and introduce so many syntax variations? The
following should be sufficient:
import underscore as _; // var _ = require('underscore');
And there should be an API (not a language construct) to import a module
dynamically (and asynchronously). Something like:
promise =
This would give the same power / flexibility as CommonJS and a simple
compatibility path. This would eliminate the default exports problem
because it would allow a module to export a function. It is also easy to
explain.
So this is basically the sugar over CommonJS modules solution. But
On Sat, Jun 28, 2014 at 9:03 AM, Kevin Smith zenpars...@gmail.com wrote:
Static checking on exported members feels odd.
Static checking of imports and exports has well-known advantages and would
help the long-term viability of the language.
Enumerating these specific advantages would
What if the Loader spec had some attention given to match AMD/CommonJS for
some cases and leave the new syntax for the new module semantics. Really
what we want is for non-es6 module systems to be able to hook into the
loader registry in a way that makes sense for them and will also make sense
for
Static checking of imports and exports has well-known advantages and
would help the long-term viability of the language.
Enumerating these specific advantages would inform this discussion. These
advantages are not well-known. Many developers have experienced the
disadvantages of complex
Static checking will be limited anyway. If you want to go this way you shoud
use typescript.
Big projects are perfectly manageable with CommonJS from my experience with a
20+ team. The trick is to enforce code reviews and unit tests.
CommonJS falls a bit short on the import side because
Maybe, I cannot see all the landscape, but a minor comment, in my limited
English
Related to:
## Early Errors and Warnings ##
Usually, I obtain the same benefit running the tests (and more, test that
were the product of TDD workflow). In this way, I'm sure not only of no
removal of something I
Static checking will be limited anyway. If you want to go this way you
should use typescript.
That's the point that I'm trying to make, shops will choose other languages
that provide more static information. We should be thinking about
expanding the user base and ensuring that JS is a viable
Usually, I obtain the same benefit running the tests (and more, test that
were the product of TDD workflow). In this way, I'm sure not only of no
removal of something I needed, but also the underlying behavior of imported
modules are still the same. Relaying on static imports only warns me
On Thu, Jun 26, 2014 at 4:50 PM, Russell Leggett russell.legg...@gmail.com
wrote:
//import a single named export
import foo from bar;
//import multiple named exports
import foo, baz from bar;
//alias an imported named export
import foo as fooAlias from bar;
On Fri, Jun 27, 2014 at 3:41 AM, Michał Gołębiowski m.go...@gmail.com
wrote:
On Thu, Jun 26, 2014 at 4:50 PM, Russell Leggett
russell.legg...@gmail.com wrote:
//import a single named export
import foo from bar;
//import multiple named exports
import foo, baz from bar;
On Thu, Jun 19, 2014 at 4:04 PM, David Herman dher...@mozilla.com wrote:
On Jun 19, 2014, at 3:31 AM, Michał Gołębiowski m.go...@gmail.com wrote:
Compare these 3 forms of importing all the module lodash bindings to
an object _:
```js
var _ = require(lodash); // Node
import * as _ from
On Fri, Jun 27, 2014 at 9:44 AM, Russell Leggett russell.legg...@gmail.com
wrote:
No, that example would be:
import mkdirp as mkdir;
Its actually shorter than node.
But in current proposal the module object cannot be a function from what I
understand. So you'd have to create a named
Some observations:
* I think the 'import * as x' syntax for module imports is not an
improvement, for at least two reasons:
- It raises the expectation that you can actually write 'import *
from' (as already noted in this thread).
- It removes the syntactic marker for binding a module
- Either we think real modules are an improvement, and checking is
important. Then the model and the syntax should be consistent about
that. Moreover, checking needs to consistently apply, no matter how a
module and its components are defined or accessed.
- Or we come to the conclusion
My opinion is that CommonJS and AMD work today and will continue to work
into the future so we should optimize for the ideal looking forward, not
backward case when adding to the language. Loader will still be
overload-able and since both CommonJS and AMD require a library today it
seems
From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of Kevin
Smith
The second option, on the other hand, will take us back to the drawing board
and I don't see how we can do that within the ES6 timeline.
We should not be concerned about timeframe in terms of what official Ecma
From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of Matthew
Robb
My opinion is that CommonJS and AMD work today and will continue to work into
the future so we should optimize for the ideal looking forward, not
backward case when adding to the language.
While this is a
We should not be concerned about timeframe in terms of what official Ecma
spec revision modules land in. ES has moved to a train model, recognizing
that it's more important when features ship in browsers than when Ecma
publishes a copyrighted document containing the features.
Fair enough -
+1
On Fri, Jun 27, 2014 at 6:39 AM, Matthew Robb matthewwr...@gmail.com
wrote:
My opinion is that CommonJS and AMD work today and will continue to work
into the future so we should optimize for the ideal looking forward, not
backward case when adding to the language. Loader will still be
+1
Yeah - obviously +1 from me as well.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
On Fri, Jun 27, 2014 at 3:52 AM, Michał Gołębiowski m.go...@gmail.com
wrote:
On Fri, Jun 27, 2014 at 9:44 AM, Russell Leggett
russell.legg...@gmail.com wrote:
No, that example would be:
import mkdirp as mkdir;
Its actually shorter than node.
But in current proposal the module
var mkdirp = require('mkdirp');
Exactly. In ES, you would see this:
import { mkdrip } from mkdirp;
Python has a somewhat similar module system, and import-renaming is the
exception, not the rule. Also, I've never heard anyone complain about
having to know the name of a module
Ok, so can I just ask a serious question. I looked at the mkdirp library,
and in their own documentation, they use:
var mkdirp = require('mkdirp');
So let's say in the new world order, no default exports, this is a named
export mkdirp. Is it *really* that bad a thing to just use the
On Fri, Jun 27, 2014 at 10:11 AM, Kevin Smith zenpars...@gmail.com wrote:
var mkdirp = require('mkdirp');
Exactly. In ES, you would see this:
import { mkdrip } from mkdirp;
Python has a somewhat similar module system, and import-renaming is the
exception, not the rule. Also,
I wrote up a gist summarizing the different proposals that were being
tossed around, it mainly says the same things as Andreas, just not as well
https://gist.github.com/calvinmetcalf/5d9a88abaa9fe094e960\
On Fri, Jun 27, 2014 at 10:02 AM, Kevin Smith zenpars...@gmail.com wrote:
+1
Yeah -
:(
From: Andreas Rossbergmailto:rossb...@google.com
Sent: 2014-06-27 09:07
To: David Hermanmailto:dher...@mozilla.com
Cc: es-discuss@mozilla.orgmailto:es-discuss@mozilla.org
Subject: Re: ModuleImport
Some observations:
* I think the 'import * as x' syntax for module
My opinion is that CommonJS and AMD work today and will continue to work
into the future so we should optimize for the ideal looking forward, not
backward case when adding to the language.
I think this statement points the way to something that we haven't yet
discussed.
A general question
On Fri, Jun 27, 2014 at 9:07 AM, Andreas Rossberg rossb...@google.com
wrote:
- It removes the syntactic marker for binding a module identifier.
That is problematic because (a) module identifiers come with extra
static checks on their uses (or so I thought, see below), and it is
(b) future
I'm echoing Kevin here.
I'd hope ES6 modules would offer me, a programmer working on large
complex JS web apps, something more then what CommonJS/AMD offers.
I work with codebases of 1K+ JS classes, 200K+ LOC and with many
dependecies that are updated frequently.
When our teams update depedencies
On 27 June 2014 18:36, C. Scott Ananian ecmascr...@cscott.net wrote:
On Fri, Jun 27, 2014 at 9:07 AM, Andreas Rossberg rossb...@google.com
wrote:
- It removes the syntactic marker for binding a module identifier.
That is problematic because (a) module identifiers come with extra
static
On Fri, Jun 27, 2014 at 3:17 PM, Andreas Rossberg rossb...@google.com
wrote:
I think you are missing the central problem. If imports/exports are to
be statically checked, then module bindings, their exports, and their
uses have to be statically recognisable and analysable. That prohibits
On 27 June 2014 17:32, Kevin Smith zenpars...@gmail.com wrote:
So to me the path forward is clear: we keep real modules, axe the default
feature, and take a temporary hit of dissatisfaction from existing users so
that we can expand the JS user base.
Note that the other half of my argument was
import {f, g, h} from url
f(); g(); h()
or
module M from url
M.f(); M.g(); M.h()
These should be freely interchangeable -- the programmer shouldn't
need to pick between getting import checking but polluting the scope
and making uses less readable, or the other way round. The
On 27 June 2014 21:26, C. Scott Ananian ecmascr...@cscott.net wrote:
On Fri, Jun 27, 2014 at 3:17 PM, Andreas Rossberg rossb...@google.com
wrote:
I think you are missing the central problem. If imports/exports are to
be statically checked, then module bindings, their exports, and their
uses
On Fri, Jun 27, 2014 at 3:34 PM, Andreas Rossberg rossb...@google.com
wrote:
All this means is that there will effectively be two different module
systems, and in practice, every module provider has to pick one. Which
is a problem, not a solution.
...this is why I've been arguing strongly
The module author has the choice to re/structure his module to allow lazy
binding/checking *iff the users demand*.
All this means is that there will effectively be two different module
systems, and in practice, every module provider has to pick one. Which
is a problem, not a solution.
On 27 Jun 2014 21:29, Andreas Rossberg rossb...@google.com wrote:
Note that the other half of my argument was that real modules are
only worth the complexity when they provide checking _consistently_.
That is, it shouldn't matter whether I write
import {f, g, h} from url
f(); g(); h()
Andreas, I hope you're not just getting my hopes up with the
possibility of checking ModuleImports too.
That would be great. I was disappointed that they weren't originally.
Making
module fs from 'fs';
fs.readFile(...);
and
import {readFile} from 'fs';
equivalent in terms of
On Wed, Jun 25, 2014 at 4:50 PM, C. Scott Ananian ecmascr...@cscott.net
wrote:
@John Barton: Yes, ideally that syntax would work as well when you don't
need a namespace. But sometimes you do need a namespace, even if you don't
care precisely what it is:
```
import {format} from 'url';
On Thu, Jun 26, 2014 at 8:15 AM, Kevin Smith zenpars...@gmail.com wrote:
I agree, and importing as a namespace is what ModuleImport is all about.
Crazy idea: what if we had this:
// ModuleImport: import Identifier from StringLiteral
import fs from fs;
import url from url;
Now the author can choose to export more things later without making
breaking changes to the module. The only downside to this is the
(apparently mandatory) curly braces around the imported object. If single
export/import becomes the convention with ES6 modules then users will be
forced to
Now the author can choose to export more things later without making
breaking changes to the module. The only downside to this is the
(apparently mandatory) curly braces around the imported object. If single
export/import becomes the convention with ES6 modules then users will be
forced to
On Thu, Jun 26, 2014 at 10:50 AM, Russell Leggett russell.legg...@gmail.com
wrote:
To me, though, that goes back to the destructuring/not destructuring
aspect. Maybe this has floated by during the bikeshedding, but why not
something like:
//import a single named export
import foo
On Thu, Jun 26, 2014 at 9:50 AM, Russell Leggett russell.legg...@gmail.com
wrote:
To me, though, that goes back to the destructuring/not destructuring
aspect. Maybe this has floated by during the bikeshedding, but why not
something like:
//import a single named export
import foo
1 - 100 of 175 matches
Mail list logo
