Expose property doesn't work when requiring a module name

[tleunen]

With the latest version (5.9.1), aliasing a module name doesn't work anymore. browserify -r fs:browserify-fs doesn't create the alias.
With an older version (4.2.3), an alias was created with the same command.

No issue with specifying a file instead of a module name.

[nathanbowser]

I ran into this issue last week. I think it may be a dup of #839. It looks like #839 is tied to the programmatic approach and this is tied to the command line interface, though. I ran into the problem using the command line interface.

[bmpvieira]

I have this issue trying to use the command line with browserify-fs. Browserify 3.46.1 works but it seems that anything above 4.0.0 fails.

[iamrandys]

+1 Only fails when using a module name.

[gobwas]

+1

[programmarchy]

+1 browserify 6.x breaking using the CLI -r option with export alias

[shenanigans]

Issue also exists when not using the cli. Personally spotted at 6.1.0. The expose property on a file is not honored and cannot be resolved later.

bundle.require (tmpFilePath, { expose:'configuration' });

This line on its own with no other source files bundled is sufficient to trigger "cannot find module configuration from [absolute directory path]"

[programmarchy]

Adding more info, this problem only occurs when using the --full-paths option.

Here's the gist: https://gist.github.com/programmarchy/1655e571b6bb36f17c02

(I'm using browserify 6.2.0)

[programmarchy]

Did a little spelunking, and found a clue in index.js:297

    var dopts = {
        index: !opts.fullPaths && !opts.exposeAll,
        dedupe: true,
        expose: this._expose
    };

From deps-sort:

opts.index - when true, for each module-deps row, insert row.index with the numeric index and row.indexDeps like row.deps but mapping require strings to row indices

The whole point of using --full-paths is to use the full path instead of a numeric index, but that does appear to be what's causing the issue of the required module not being found. Going to look deeper into how deps are looked up in other parts of browserify...

[programmarchy]

Pinging @shenanigans @gobwas @iamrandys @bmpvieira @nathanbowser @tleunen

Is the error you are getting: "Uncaught Error: Cannot find module [path to your module]" ?

Just want to make sure we are all discussing the same issue.

[shenanigans]

Roger. Currently depending ^5.8.0 as workaround.

[programmarchy]

After more investigation, I think this is related to browser-pack step of browserify.

When I bundle without --full-paths, the packing in my gist above looks like this:

{"events":2,"nyan":undefined}

With --full-paths, it looks like this

{"events":"/usr/local/lib/node_modules/browserify/node_modules/events/events.js","nyan":"/path/to/kitten.js"}

I think that it should instead look like this:

{"events":"/usr/local/lib/node_modules/browserify/node_modules/events/events.js","nyan":undefined}

In fact, when I manually patch my bundle, it works. Still looking into why.

[tleunen]

With the example from my first post, here is what I get, with the version 6.2.0

browserify -r fs:browserify-fs
Error: Cannot find module 'browserify-fs' from ...

[nathanbowser]

@programmarchy Yea, if I run something like this:

browserify -r lodash:underscore -r ./assets/js/main.js:main

It will spit out

Error: Cannot find module 'underscore' from '/Users/koopa/dev/dash/

That's using browserify 6.2.0

[nathanbowser]

And it doesn't look like the usage of --full-paths makes a difference on my end.

[nathanbowser]

Sorry for the comment spam, but I should also mention I'm still using browserify@4.2.3 because the 5.x and 6.x versions have this problem.

[Fedia]

@nathanbowser, try aliasing in package.json. Works for me with browserify 6.2.0

  "browser": {
    "fs": "browserify-fs"
  }

[mwiencek]

#991 fixes the combination of fullPaths and expose for me, if anyone else wants to see if that works for them.

[athaeryn]

I was having the same issue and #991 fixed it for me as well.

[nervo]

Same issue too, #991 fixed it too

[olivierphi]

I ran into the same blocking issue too. #991 fixes it too!

[benji07]

👍

[yoh]

👍

[woecifaun]

👍

[tleunen]

With the example, I still get the same error as before, with latest version. Is it something browserify won't support anymore? @substack

browserify -r fs:browserify-fs
Error: Cannot find module 'browserify-fs' from ..

[slorber]

@tleunen I still have the problem too. The build fail only when using an alias/expose name, even with 6.3.3

[o0x2a]

I also have this problem both in cli and in code using b.require('backbone', {expose: 'bb'}) . I am using Browsify 8.1.1

> browserify -r backbone:bb -o test.js

Error: Cannot find module 'bb' from 'd:\project'

@substack should we open another issue ?

Update:
Using module path instead of module name seems working, the following execute without error:

> browserify -r ./node_modules/backbone:bb -o test.js

[milyord]

+1

Using module name instead of module path is still broken in 9.0.3

[syadykin]

+1

Same here, import by name doesn't work with expose feature.

[ghost]

Published @ElNounch's fix in 9.0.8.