allow to specify global-transform in package.json of root project

[thlorenz]

I would like to specify global-transform not only on the command line, but also inside the package.json of the root project that I'm browserifying.

This way browserify will pick them up if run via tools like testling, zuul and beefy.

Here is a package.json example:

{
  "browserify": {
     "transform": [ "local  transform" ],
     "global-transform": [ "global1", "global2" ]
  }
}

The idea is that the global-transform field will be ignored for all packges but the root package. However if found inside the root package they'd be added to the browserify transforms via; b.transform(x, { global: true }).

I''m willing to do a PR for this, but wanted to hash out the details first.

I see a _resolve function that resolves a package.json, but as far as I can tell it is only used in browser-resolve, but not by top level browserify. Could we use that same function to try to resolve the root package for the given entry?

As an alternative we could use find-parent-dir to find the root package instead of using _resolve.

[ghost]

A few things: if there are multiple entry files and multiple package.json files, how does browserify decide which one should win? If I do:

browserify a/main.js b/main.js

and there are a/package.json and b/package.json files, what should happen?

If global-transforms goes in as a configuration option how would these interact with arguments given on the command-line?

[thlorenz]

Really good points. Resolving the package.json I'd actually opt for the one in the cwd, since we are trying to find the root package. The idea with resolving for entry file was just me trying to make this a little more safe, i.e. what if you are running from outside of your package -- however very unlikely. So I'd suggest that finding the package.json in the cwd or the closest one above it should be the approach.

WRT command line args we have to decide between two options:

• a) command line args win, i.e if they are present the global transforms in the package.json are ignored
• b) command line args are combined (i.e. concated to the ones in package.json)

I'd opt for a).

How is this handled for local transforms right now actually? This should be a similar situation for the ones specified on the root package when I'm supplying them also via --transform.

[thlorenz]

On another thought, would you really specify entry files to be inside packages you depend on? And then even two of them? I've never seen that happen.

Wouldn't you instead have an entry file in your package that does:

require('a');
require('b');

?

[ghost]

There's a very good use-case for having entry files live deep inside directory structures since entry files are the code that runs when the application boots so it's a good place to put initialization logic. Otherwise you load files just for the side-effects, which is weird.

[thlorenz]

Ok, so what about using cwd as explained above?

Also what's your take on my suggestion for handling cli transforms when package.json transforms are present as well?

[thlorenz]

@substack getting the feeling we may not be talking about the exact same thing:

entry files live deep inside directory structures are the code that runs when the application boots

As long as those are not inside node_modules and thus would have their own package.json that is no problem and covered by the original approach I suggested. In this case we'd keep looking upward from both files to find a package.json and find the one in the root of the package/app since they are both part of it.

What I thought wasn't likely is that you'd have a file inside a dependency as an entry file, i.e. ./node_modules/a/main.js.

So for this case we could just consider the first entry file to find the package.json in a parent folder. That would work, since the other entry would resolve to the same package.json. In summary as long as people don't do anything very odd this approach will work.

So here are the steps I'm suggesting:

1. when about to resolve and bundle, look if we already have global transforms defined via cli
2. f yes, do nothing and end here
3. if no, find the package.json next to or in the closest parent dir to the first entry file
4. look for global transforms in that package and if found add them to the browserify instance

step 3. can be changed to:

• find the package.json next to the current working dir or in the closest parent dir of it

in case the entry file approach is still an issue despite what I outlined above.

Let me know if those steps would work and/or how they' need to be tweaked. Thanks.

[joshgillies]

Has there been any further thought paid toward this issue. I've just spent the best part of today trying to work out a way to specify global transforms from package.json.

[kumavis]

i want it :heart: