Browserify cannot find module 'waypoints'

[crispouille]

Hey @imakewebthings ,

Recently installed npm waypoints, working on browserify + vueJS(vueify), and it seems to be complicated to require waypoints. Any advice ?

[imcodetolive]

Hey @crispouille,

It's necessary add the main property to package.json and fix something like this. So IMO browserify-shim is the best solution, at least for now.

[mkstix6]

Hi I also had this problem. Are these fixes being baked into the next waypoints release or is this something I'll need to keep in mind.

I'm just thinking about when the other developers in my team run npm install.

[mkstix6]

For now i have it working with var waypoints = require("../../node_modules/waypoints/lib/jquery.waypoints.js”); (my main.js is inside ./app/scripts/)

[jarodtaylor]

I'm using babel so I tried to use

import Waypoint from 'waypoints'

In order for that to work, I had to go into the Waypoints package.json file and add "main":"./lib/noframework.waypoints.js".

Unfortunately, I'm getting this error in my browser when I try to use it:

Uncaught TypeError: r.default is not a function

That's generally an error when you're trying to reference a script that it can't find. But I can type Waypoint in my Chrome console and it finds it, just fine.

[crispouille]

As answered previously, to "fix it" i'm using browserify-shim to create a direct link to the noframework.waypoints file ! It works well, however I'm waiting for an up from the creator :+1:

[peduarte]

Also getting this...

[crispouille]

@peduarte Don't know if the author has fixed the issue, but as said previously, I used browserify-shim to fix waypoint ! I think the best is to document urself about browserify-shim. Good thing to know ! Maybe an exemple of my package.json will help you to use it :

"devDependencies": {
    "browserify": "^11.2.0",
    "browserify-shim": "^3.8.10"
  },
"browser": {
    "waypoints": "./node_modules/waypoints/lib/noframework.waypoints.js"
},
"browserify-shim": {
    "waypoints": {
      "exports": "waypoints"
    }
},
"browserify": {
    "transform": [
      "browserify-shim"
    ]
}

[peduarte]

Thanks!

[jarodtaylor]

I ended up just creating a waypoints.commonjs.js file based off of a shim and included it in my scripts/vendor directory which I just referenced as you would, normally:

import 'Waypoints' from 'vendor/waypoints.commonjs'

If/when it's fixed on the node module, I'll revert back to using it the traditional way.

[imakewebthings]

I'm closing duplicate tickets to focus the discussion here. I'm also closing PR #426. First, some responses to things from that PR.

Yes, I don't understand why this isn't the single highest priority. In late 2015, I don't understand how one can expect a JS library, plugin, whatever to persist into the future without UMD or at least commonjs support. So many people today are using Webpack, Browserify, etc. If I magically am afforded some time in the near future, I would be happy to try to help make this happen.

This is the single highest priority for this project. Weighing all the things that are happening in my life at the moment, as the sole maintainer of Waypoints, the highest priority for Waypoints is still quite a ways down in my list. As you (@asalisbury) and others have expressed an interest in helping out, let's see if I can lay out what questions and concerns I have, what would be needed in a PR, and maybe everyone here can talk (and code) out a solution.

As for PR #426 itself: As I stated in a comment there, the PR is only adding a file to lib instead of using the build process to build it from src. That is why I'm closing it. Any PR needs to be something built from src.

It would be interesting if there were a way to let people import the jQuery or Zepto builds as well, but I'm 100% ok with saying main: lib/noframework.waypoints.js.

I'm also cool with adapting the build process to change what is currently in the Noframework build to include a UMD pattern. I'd prefer it to creating another build. But if it's prohibitively hard to modify the existing build vs. create a new one, that's fine too.

What does the story become for people trying to use the shortcuts? I'm also ok with the answer in the short term being "no story, live with it," but does anyone have good ideas here? Would it ultimately be easier to have the shortcuts each live in their own repo and have their own npm packages? Sticky and Infinite both require the jQuery build currently, so there's that issue again of only exposing the Noframework build...

Any thoughts? Anyone excited to take on a new PR for the minimal case of exporting the Noframework build?

[gearmobile]

// waypoints package.json

"main": "lib/jquery.waypoints.js",

// app.js

import $ from 'jquery';
import svg4everybody from 'svg4everybody';
import swiper from 'swiper';
import waypoints from 'waypoints';

$(() => {

  // svg sprite
  svg4everybody();

  // header slider
  swiper('.swiper-container', {
    pagination: '.swiper-pagination',
    paginationClickable: true,
    autoplay: 6500,
    effect: 'fade'
  });

  // hide \ show topheader
  waypoints('.header', function ( direction ) {
    if ( direction === 'down' ) {
      $('.topheader').fadeIn();
    } else if ( direction === 'up' ) {
      $('.topheader').fadeOut();
    }
  }, {offset: '5%'});

});

In browser console error:

TypeError: t is undefined
...}var t=window.jQuery,n=window.Waypoint;t.each(["innerHeight","innerWidth","off",...

... and plugin waypoints not works. What to do?

[acstll]

@gearmobile using the main key in package.json is useless because the library is not "exporting" anything.

A sane way to use this with browserify or weback is to do just this:

// this attaches `Waypoint` to window
require('waypoints/lib/noframework.waypoints.js')

a that's it.

@imakewebthings I'd be glad to think of a way to create a node-compatible build out of src/, though it looks quite challenging for the way the library is built (relying on window.Waypoint to be present in many files). I'll come back if any ideas come up.

[sospedra]

+1

[summerisgone]

I've started migration to commonJS modules in my fork. Hope I'll afford it.

[jwkicklighter]

Been almost a year at this point, is there any activity on this? I see that there was work done on the 5.0 branch.

[Frondor]

Just stop using the library. I had a few templates using waypoints and started to get rid of this since its no longer maintained as it used to be.

[screendriver]

@Frondor what do you use instead?

[ioloie]

I imagine the intersection observer API (or its polyfill) is the preferred way of achieving a lot of the use cases for waypoints

[Frondor]

@screendriver depends on my needs. Aos for animations, my own script for any other scrolling related task

[jwkicklighter]

@Frondor @ioloie It is disappointing that this isn't really being maintained, but that doesn't mean it's broken. I'll definitely look into intersection observers though, hadn't heard of that before. For the time being, I'm able to use Waypoints by just doing a require() of the library. Works well enough for our easy case, and doesn't need a polyfill.

[bflopez]

Adding something like require("../../node_modules/waypoints/lib/jquery.waypoints.js”); worked for me at first but then as someone mentioned, this makes Waypoints attach itself to window. When using Angular Universal this makes it so server side code can't run. So far haven't found a way to only import it client side in the TypeScript.

[derwaldgeist]

Is there an alternative library that works with modern JavaScript, i.e. ES6 modules?

[josephrexme]

@derwaldgeist you can look into https://github.com/scroll-out/scroll-out

[derwaldgeist]

@josephrexme Thanks!

[cookatrice]

@josephrexme Thanks. You save my time. :)

[fmquaglia]

@josephrexme Thanks a lot, man. You saved the day.

[1aurabrown]

Is this being fixed?

[josephrexme]

Latest commit was September 2016 @1aurabrown . Just go ahead and use the other recommended tool