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 👍

[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?