Unable to find a browserify-shim config section in the package.json

[bclinkinbeard]

I'm getting this when trying to require a file outside my app's directory. So just the presence of require('../hmm') will spit out

Error: Unable to find a browserify-shim config section in the package.json for /Users/bclinkinbeard/Code/scratch/bug-reports/b-shim/hmm.js
    at /Users/bclinkinbeard/Code/scratch/bug-reports/b-shim/app/node_modules/browserify-shim/lib/resolve-shims.js:163:38
    at /Users/bclinkinbeard/Code/scratch/bug-reports/b-shim/app/node_modules/browserify-shim/node_modules/mothership/index.js:27:31
    at testDir (/Users/bclinkinbeard/Code/scratch/bug-reports/b-shim/app/node_modules/browserify-shim/node_modules/mothership/node_modules/find-parent-dir/index.js:20:36)
    at /Users/bclinkinbeard/Code/scratch/bug-reports/b-shim/app/node_modules/browserify-shim/node_modules/mothership/node_modules/find-parent-dir/index.js:26:7
    at Object.cb [as oncomplete] (fs.js:168:19)

[bclinkinbeard]

I guess this is actually a duplicate of #44, but the repro case is super simple here. Unzip http://cl.ly/2d0a1f1p3P0n, npm install, then browserify entry.js > bundle.js and you will see the error. If you comment out the require('../hmm') line in entry.js things work as expected.

It's not feasible or realistic to insist that every file required by an application using b-shim will have a package.json with shims configured.

[thlorenz]

Could you please put whatever is in that zip file into a public github repo?
That way I can look at the code right there, add comments, PR etc.

Thanks.

[bclinkinbeard]

https://github.com/bclinkinbeard/b-shim-61

[thlorenz]

Thanks, will have a look.

[guillaume86]

• 1 I have the same problem with the same use case

[pmdarrow]

Any ideas how to fix this? I'd love to use browserify-shim but this is a showerstopper for me.

[thlorenz]

I had a look and believe the reason for this failing is that hmm.js is outside of the project (i.e. the app which contains the package.json).
The correct setup is to have all your files inside (or below) the dir that contains the package.json.

[pmdarrow]

This worked for me, thanks.

[timruffles]

browserify supports having files outside of a 'app root', so I think browserify-shim should too! Seems like a valid bug to me

additionally, a lot of people these days are dividing big apps into multiple modules each with a separate package.json. without this capability you're stuck with a monolithic package.json

[kopepasah]

+1 for enabling browserify-shim to not have to be included in the app root. I personally keep all development code in a separate directory from production code (including package.json for development).

Besides, if browserify works when not in the app root (according to @timruffles), then the shim should also.

[bendrucker]

browserify-shim traverses upwards from each file looking for the "mothership" package.json. This uses mothership and stops when it finds a package with a browserify-shim configuration.

There's no reasonable way around this. If you have files above the package, there's no way for browserify-shim to figure out how to handle them. They get transformed but b-shim has no way to decide how to operate on them.

This doesn't preclude you from splitting up modules into smaller modules though. There just has to be a package.json at or above every required file with browserify-shim defined, even if it's just an empty object.

[timruffles]

It doesn't need to do anything to the files I'm requiring, it should just
pass them through.

On Wed, Apr 1, 2015 at 12:46 PM, Ben Drucker [email protected]
wrote:

browserify-shim traverses upwards from each file looking for the
"mothership" package.json. This uses mothership
https://github.com/thlorenz/mothership and stops when it finds a
package with a browserify-shim configuration.

There's no reasonable way around this. If you have files above the
package, there's no way for browserify-shim to figure out how to handle
them. They get transformed but b-shim has no way to decide how to operate
on them.

This doesn't preclude you from splitting up modules into smaller modules
though. There just has to be a package.json at or above every required file
with browserify-shim defined, even if it's just an empty object.

—
Reply to this email directly or view it on GitHub
#61 (comment)
.

[bendrucker]

That's not an assumption that can be made though. The only way to allow arbitrary files to be required is if b-shim failed silently if no shim configuration could be located.

[timruffles]

Yup - sounds like a good behaviour to me. Why modify more behaviour than
you need to? Compose well.

On Wed, Apr 1, 2015 at 2:48 PM, Ben Drucker [email protected]
wrote:

That's not an assumption that can be made though. The only way to allow
arbitrary files to be required is if b-shim failed silently if no shim
configuration could be located.

—
Reply to this email directly or view it on GitHub
#61 (comment)
.

[bendrucker]

I didn't mean to imply that silent failure is on the table. Someone without knowledge of Browserify internals could reasonably expect that requiring a file above the package would work with browserify-shim.

The only thing we can consider for the small number of users affected by this would be to support a transform option that would ignore the specific case of mothership succeeding but not finding anything. Even that I'm not sure about. It's a lot of maintenance cost for a use case that still doesn't make sense to me.

[brettdh]

I'll toss in another use case for this behavior: incrementally moving a large legacy codebase to use browserify. Here's a brief overview of what we're trying to do at my company.

Naturally our JS code is composed of our own code and a number of third-party libraries. We store those libraries in a separate repository and move them into place at build time. We are trying to start introducing browserify into our code base, for both modularizing our own code and simplifying dependency management for third-party libs. This requires being able to specify the different paths for the libs we're loading, which we can do in browserify via setting search paths, but not (AFAICT) in browserify-shim.

Our current workaround is to put a package.json file with a browserify-shim section in the common root directory of our entire product repo (where the third-party packages get installed), but this is not ideal, as there's now a file floating around that has apparently nothing to do with its siblings. (Actually, maybe this is just a feature request for browserify-like search paths, or to use the ones that we already have configured for browserify. Sorry if I'm missing something fundamental here; I'm pretty new to this world. :-) )

Our first attempt had the package.json in our js folder point to a shims configuration file that included relative paths into our third-party js folder, and we had expected that this would work, since we had defined a shims section with relative path to each dependency, but browserify-shim choked until we moved that browserify-shim section to a package.json in the common root dir. That's why we feel this is an unnecessary requirement; we'd told browserify-shim how to shim the dependency via relative paths, but it required us to have the package.json file in a particular location instead, even though it had the same contents (though obviously the path changed).

If this really is a dead-end, I would really appreciate your advice as to how best to handle this case.

Thanks!

[bendrucker]

If this really is a dead-end...

Happy to clarify that it is. b-shim needs to read config from your package. All it gets for each file is the file path and the file contents. So by definition it can't handle files above the package. I know that's potentially frustrating but there's no choice here.

[pieterjandesmedt]

Workaround (mostly for my own reference)
I have a directory structure like this:

|_ /app1
|_ /app2
|_ /app3
|_ /common_components (between all apps)

The common_components directory is symlinked from within the app directories.

I also got this error on code within the common_components directory, none of which have a package.json. I added package.json to the root directory like this:

|_ /app1
|_ /app2
|_ /app3
|_ /common_components
|_ package.json

This package.json just contains

{
    "browserify-shim": {}
}

Not an elegant solution, but this kills the error.

[Fauntleroy]

I'd like to add another case where this is a problem:

I'm working on a branch of a module I'm using in my project, so I've used npm link to pull in my local copy. This is resulting in the following error, since the module I'm including doesn't have a browserify shim config:

Browserify Error { [Error: Unable to find a browserify-shim config section in the package.json for /Users/Tim/Repos/react-player/lib/ReactPlayer.js while parsing file: /Users/Tim/Repos/react-player/lib/ReactPlayer.js]
  filename: '/Users/Tim/Repos/react-player/lib/ReactPlayer.js',

[clementoriol]

Adding my case too :
On staging / production we're using a symlinked node_modules folder. It's actually outside of the project (in a shared folder), but there's a symlinked folder in the project, near the package.json.
Browserify-shim doesn't seem to be able to follow the symlink, and we're having the error described in this thread.

Could this be an issue in mothership (https://github.com/thlorenz/mothership), which is used to locate the package.json ?

Copying our package.json near the "real" node_modules folder fixes the issue, but feels dirty.

[jessepollak]

I'm also having this issue with the case that @Fauntleroy describes — where I'm npm linking in modules that I'm working on.

[bucha]

@pieterjandesmedt That workaround helped wonders — Thank you!
I'm also npm linking a module into my project.

[seifertd]

Ditto having problems using yarn this time to link in dependent modules during development:

./my-module-1/:
yarn link
./my-module-2/:
yarn link my-module-1

Any call to browserify in my-module-2 will generate this error. I suppose we could "work around" it by deleting the link and copying into node_modules what was previously linked to, but that is sad 😿