by

Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    Matti Lankinen
    @milankinen
    however when you are using module.export = ... you are actually replacing module's content and the replaced content is shown outside
    Muhammad Aref
    @LeoAref
    is module.exports === exports ??
    if yes, why we can't use exports = ... ?!
    Matti Lankinen
    @milankinen
    because then module.exports !== exports
    Muhammad Aref
    @LeoAref
    because module.exports is the same as exports and is initially set to an empty object. :)
    I don't understand this: so assigning a new value for exports instead of module.exports masks the original reference. here is the clue
    Matti Lankinen
    @milankinen
    not like that
    think your module as a function:
    const module = window
    module.exports = {}
    function yourModule(exports) {
    
    }
    yourModule(module.exports)
    now if you re-assign exports variable, nothing gets changed outside your function
    Muhammad Aref
    @LeoAref
    why, we send module.exports by reference, so exports inside the function is reference to module.exports outside the function. Right?!
    Matti Lankinen
    @milankinen
    but your are not modifying the contents, only the reference
    that's why
    Muhammad Aref
    @LeoAref
    ah, by reassigning the content, we lose the reference, Thanks :thumbsup:
    Bill Gloff
    @billgloff
    blob
    Anyone ever come across this issue of LiveReactload starting up twice? I have it configured in Gulp and I don't see any problems: Here's what my output looks like:
    var b = browserify({ cache: {}, packageCache: {}, entries: [entry], transform: config.settings.transform, plugin: [ lrload ], debug: config.debug, extensions: config.extensions });
    Matti Lankinen
    @milankinen
    Hmm, could you show your gulpfile.js?
    Bill Gloff
    @billgloff
    ok I'll create a gist
    Matti Lankinen
    @milankinen
    thanks!
    Bill Gloff
    @billgloff
    It's broken up into many different files and we're do a recurse: true on it But here's what the browserify.js looks like https://gist.github.com/billgloff/c66b9be9f7b1fe556282fcf1ebda34c8
    Matti Lankinen
    @milankinen
    hmmm
    any chance that some other task triggers the browserify task multiple times?
    Bill Gloff
    @billgloff
    possibly....thats actually what I was checking just now
    Jeff Langston
    @jlangston
    Anyone ever seen syntax errors from using livereactload in the generated bundle. It seems like source property is getting truncated at $ characters. One example I am seeing is in the bundle is a syntax error like this.
      "44": {
        "id": 44,
        "index": 44,
        "file": "projectdir/node_modules/core-js/modules/$.collection-strong.js",
        "source": "'use strict';\n\nvar _typeof = typeof Symbol === \"function\" && typeof Symbol.iterator === \"symbol\" ? function (obj) { return typeof obj; } : function (obj) { return obj && typeof Symbol === \"function\" && obj.constructor === Symbol ? \"symbol\" : typeof obj; };\n\nvar $ = require('./;
        return __byId(moduleKey(scope$$, myId, name), false);
    Where it is breaking around a line in the source that has require('./$');
    Matti Lankinen
    @milankinen
    hmmm
    Jeff Langston
    @jlangston
    Poking around in the main.js file of the browserify-plugin folder I can see where the structure is being generated but it wasn't obvious to me what is causing my issue.
    Matti Lankinen
    @milankinen
    yeah sounds very strange
    Jeff Langston
    @jlangston
    That's what I thought I wasn't sure if this was an issue I. That file or one of the modules used by that file
    Matti Lankinen
    @milankinen
    is it possible to get the whole bundle.js?
    Jeff Langston
    @jlangston
    It is giant because it is including everything from node modules at the moment
    Matti Lankinen
    @milankinen
    no problem if you just can share it
    Jeff Langston
    @jlangston
    On second thought there is code in it from a prIvate company module so it may not be a good idea to post. Which is not helpful in debugging the issue.
    Matti Lankinen
    @milankinen
    ok I understand
    Jeff Langston
    @jlangston
    I can see if I can widdle it down to a small example that reproduces the same error.
    Matti Lankinen
    @milankinen
    cool! You can also create an issue to github - the info you provided is enough for the decent issue already :smile:
    Jeff Langston
    @jlangston
    Will do thanks for your help!
    Jeff Langston
    @jlangston
    Well making a small example that reproduces my issue isn't as easy as I was hoping. Importing the same node module that was giving me fits works in the basic livereactload example app.
    Jeff Langston
    @jlangston
    Something I am doing in the package that I have wrapping browserify where I was trying to integrate livereactload is what is causing the issue. Applying the same tool to the livereactload basic example causes the same issue. It's somewhere in how the bundle is being generated from this file https://github.com/jlangston/gluten/blob/liveReactLoad/index.js#L51
    Jeff Langston
    @jlangston
    I did end up figuring out what I was doing wrong. Using exorcist to generate external sourcemaps was the cause of my frustration. livereactload is working great. Thanks for all the work on this!!
    Matti Lankinen
    @milankinen
    Nice! Great that you got it working! :+1:
    lsimone
    @lsimone
    hi guys!
    anybody having issues with redux?
    I currently can hot reload without Provider and Router components, but when I modify a component inside them, the page does not update despite that the build is correctly done through watchify and the client (browser) shows the "LiveReactload :: Patching complete" message
    lsimone
    @lsimone
    I guess the issue is with react-router
    everything inside it is not reloading
    Eugene Zaretskiy
    @EugeneZ
    If anyone here had problems with livereactload that they never resolved, you may want to try the new beta by installing livereactload@next. It utilizes the new react-hot-loader beta which uses newer, better strategies for keeping state between reloads, and it also means you can get all the bugfixes and advantages of react-hot-loader without new versions of livereactload which now acts as a layer between it and browserify. If you have questions about migration feel free to ask or file an issue!
    Matti Lankinen
    @milankinen
    :+1: :tada: :tada:
    Punita Ojha
    @punitaojha
    This message was deleted