Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

The plugin shorthand syntax does not (cannot?) work with Browserify #124

Closed
bpierre opened this issue Feb 21, 2014 · 12 comments
Closed

The plugin shorthand syntax does not (cannot?) work with Browserify #124

bpierre opened this issue Feb 21, 2014 · 12 comments

Comments

@bpierre
Copy link

bpierre commented Feb 21, 2014

Browserify can only analyze static requires: browserify/browserify#377 (comment)

@yyx990803
Copy link
Member

Hmmm... I guess the shorthand is only for Component-based projects then. I will clarify that in the spec.

@bpierre
Copy link
Author

bpierre commented Feb 21, 2014

Same for Vue.require: Vue.require('utils') only works because it has already been called in a static way: https://github.com/yyx990803/vue/blob/master/src/main.js#L3

A (really ugly) solution could be to require all the modules relevant for plugins in main.js…

@yyx990803
Copy link
Member

Yeah this is actually one of the reasons I use Component over Browserify... let me think about this.

@yyx990803 yyx990803 reopened this Feb 21, 2014
@bpierre
Copy link
Author

bpierre commented Feb 21, 2014

Maybe a dedicated plugin API could be provided (and documented), instead of exposing all the internal components:

// plugin-api.js
module.exports = {
    utils: require('./utils'),
    // relevant modules
}
// main.js
var pluginApi = require('./plugin-api')
ViewModel.require = function (path) {
    return pluginApi[path]
}

@vendethiel
Copy link

You could try commonjs-everywhere

@yyx990803
Copy link
Member

I'm actually thinking of shipping built versions for npm instead. This would allow me to get rid of the emitter hack and also split observer into its own package.

@yyx990803
Copy link
Member

Scrap that - browserify attempts to parse all the requires inside and throws compile time error.

@duckbox
Copy link

duckbox commented Feb 21, 2014

Yup, Browserify attempts to parse on bundle, making dynamic paths
impossible. For the likes of utils, or any other static named module
without './', you can define a list of modules in package.json,

browser : {
  "utils" : "./deps/utils"
}

etc.

On Fri, Feb 21, 2014 at 8:56 PM, Evan You notifications@github.com wrote:

Scrap that - browserify attempts to parse all the requires inside and
throws compile time error.

Reply to this email directly or view it on GitHubhttps://github.com/yyx990803/vue/issues/124#issuecomment-35772711
.

@yyx990803
Copy link
Member

So here's all modules that are exposed for plugins: utils, config, transition, observer. These are theoretically all you need. Plugins should not mess with the other parts anyway. Docs will be updated together with the next release when the plugin spec is more mature.

@marfalkov
Copy link

I think it may also true for a require.js setup when you use the almond shim.

@kewah
Copy link

kewah commented Jun 11, 2014

Vue.require() doesn't work with component/builder2 (used in component@1.0.0). With builder2, require() calls are overwritten during the build step.

For instance

var utils = require('./utils')
// become
var utils = require("yyx990803~vue@v0.10.5/src/utils.js")

Could be fixed like @bpierre has suggested:

var modules = {
  utils: utils,
  config: config,
  transition: require('./transition'),
  observer: require('./observer')
};

ViewModel.require = function (path) {
    return modules[path]
}

@yyx990803
Copy link
Member

yeah, that might be the better way to go. open to PRs!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants