Help with pathmodify.mod.dir?

gnimmelf commented 9 years ago

Hi,

I'm at the end of my rope here in trying to make this work, so thought I'd drop a line and ask the creator.

I have this:

var bundler = browserify(local_config);
var mods = config.app_paths_aliases.map(function(app_paths_alias) {
  return pathmodify.mod.dir(app_paths_alias[0], app_paths_alias[1]);
})

bundler.plugin(pathmodify, {
  mods: mods,
});

console.log(mods);

and it gives me the following console-output for mods:

[   { from: 'event/templates',
    to: '/home/flemming/workspace/dev/arch/event/templates/event',
    expose: undefined,
    type: 'dir' },
  { from: 'event',
    to: '/home/flemming/workspace/dev/arch/event/static/js/modules',
    expose: undefined,
    type: 'dir' } ]

-Does this look like a proper list of mods?

Now, in som browserify module I try

require('event/models/hs-event');

to get at the file

/home/flemming/workspace/dev/arch/event/static/js/modules/models/hs-event.js

But browserify tells me

Cannot find module 'event/models/hs-event' from '/home/flemming/workspace/dev/arch/arch/static/js/modules'

Any ideas? I think I've tried most alternatives, but there is always the option of me not groking browserify completly...

Cheers!

jmm commented 9 years ago

@gnimmelf Thanks for your interest in pathmodify!

That does look like a proper array of mods. The thing that jumps out at me right away is this:

bundler.plugin(pathmodify, {
  mods: mods,
});

The way I have it setup right now requires doing this (I'm showing the require() to help illustrate the situation -- I assume this is the same way you're defining your pathmodify variable):

var pathmodify = require('pathmodify');

// Note that the return value of `pathmodify()` is the first arg, not the export itself.
bundler.plugin(pathmodify(), {
  mods: mods,
});

Now, mind you, that was probably a stupid way for me to set it up. I'll probably change that in the next release.

gnimmelf commented 9 years ago

That, sir, was the problem; not calling pathmodify. Cheers!

As you say, would be a good idea to change it, as other browserify plugins exports the actual plugin object, not a constructor-type function.

Thank you very much!

jmm commented 9 years ago

@gnimmelf You're welcome! Thanks for your feedback.

gnimmelf commented 9 years ago

On second thought on the export; I see now that many plugins also export a constructor-type function, so you really don't need to change anything. And keeping it the way it is won't require us that use your package to update anything either...

Cheers.

jmm commented 9 years ago

On second thought on the export; I see now that many plugins also export a constructor-type function, so you really don't need to change anything. And keeping it the way it is won't require us that use your package to update anything either...

It's perhaps not totally cut and dry. The main thing is that a plugin should export the signature (b, opts), or do some special handling, if it's going to support the CLI. There's definitely an argument for not trying to use something like this (or doing anything that gnarly) via the CLI though. There's also something to be said for providing an interface consistent with other plugins. For the ones you're talking about, is the main export a constructor function? Or you mean they export something like a configure() function?

Thanks again for your feedback.

gnimmelf commented 9 years ago

By constructor-type I just meant that they export a callable.

I'm using browserify for the first time now (with gulp, not the CLI), and rushing through it, so I haven't had the time to actually look into the code of plugins I'm using, so the comment was just from glancing over my code.

Cheers.

jmm / pathmodify

Help with pathmodify.mod.dir? #2