make it compatible with babelify and es6 import syntax

[call-a3]

Hi!

Thanks for your input! Could you be more specific about the workflow you would like to use? I am aware of ES6 syntax and how babelify can convert this to ES5 using one of several loader approaches. However, shouldn't babelify already convert ES6 into require statements? How does this relate to the functionality of this transform?

[thecotne]

i have this code in my script

var modules = require('./fp/*.js', {mode: 'hash'});

if i replace that with

import modules from './fp/*.js';

it won't work because there is no mode specified

it throws error

Browserify Failed!: Cannot find module './fp/*.js' from '/js/helpers'

[call-a3]

Oh, ok, now I get what you mean :) This could be easily fixed, however you will lose a lot of customizability by default if no options object can be set... You would only be able to use one type of loader (=mode) with a specific configuration. Which mode would be best for this scenario is open for discussion...

[thecotne]

i am using mode: 'hash' everywhere

[call-a3]

I'm still thinking on this. I think I'm going to create a global config that would be applied to all require calls and can (but need not be) extended/overwritten by a local config. However, I'd like to have a well-defined test case to try out my solution. Is there any possibility you can share some example code/project with me for this purpose?

[airroom]

:+1: looking forward to this feature!

[call-a3]

I think it'll be easier to come up with a similar tool for babel itself, since it allows deeper integration with other transforms for babel (specifically experimental features of ES2015+). Maybe it's a good idea to turn this functionality into a proposal for new syntax in ES2015's import/export semantics. Imho that'd be better than blindly implementing this feature without fully understanding how it would impact the import/export semantics.

Do any of you have concrete examples of how input/output for ES2015 source would look like?

[thecotne]

i don't think ES will ever support glob importing it won't work without compiler because you can't request glob with http

so it need to be plugin of some compiler and you need gulp or webpack or browserify to work with this kind of thing

[call-a3]

That's a fair enough assumption, although HTTP does have a equivalent for * (at least for single directories), namely the index/listing of directory contents. You are probably right that globbed imports is probably not something that would make it into the actual spec of ES. Nevertheless, I'd like to find some syntax that does not cause any possible confusion with legitimate ES syntax.

For example, I'm not familiar enough with the different variants of import/export default to anticipate the different forms of those statements and how they, when containing glob patterns, should "correctly" be expanded into valid import/export statements.

So, practically, I'd really like (someone) to start building a list of before-and-after examples of a proposed syntax in ES2015 for globbed imports that covers all existing variants of import statements.

[thellimist]

How is this going?

[Torvin]

I cannot make it work with ES syntax at all. I'm not trying to bulk-import. I'm just trying to import a module that has bulk-require() inside and the build fails with

'import' and 'export' may appear only with 'sourceType: module'

In my gulpfile I have:

browserify(...).transform('babelify', { ... }).transform('require-globify')

I tried it the other way around too (require-globalify before babelify), without any visible change. What am I doing wrong? How do I make require-globalify run after babelify finishes transforming imports to require()s?

[Torvin]

Why did this get closed?..

[DRSDavidSoft]

I hope the author updates us on the issue!