elidoran / cosmos-browserify

Browserify npm modules for client side in Meteor packages
MIT License
78 stars 12 forks source link

Resolving npm packages? #22

Closed billyvg closed 9 years ago

billyvg commented 9 years ago

I'm trying to create a package that uses browserify... it's trying to resolve the npm modules inside of my application/packages directory, but the npm packages are installed in the ~/.meteor/packages directory.

Am I doing something incorrectly? This is for meteor 1.2.

elidoran commented 9 years ago

Please provide a repository I can look at or tell me what's in your files...

billyvg commented 9 years ago

https://github.com/Opstarts/basic-logger

elidoran commented 9 years ago

Thank you for providing the repository.

When I run that in an app I run into trouble.

  1. if I comment out all your package files, except the browserify one, it runs and browserifies all that stuff.
  2. when I uncomment the rollbar.js file it has trouble with Meteor.userId(). I added the accounts-base to api.use() and that file loads okay.
  3. when I uncomment _loggerbase.js it errors on the server complaining Symbol is not defined.

I'm a CoffeeScript fan, so, I don't use ES6 or Meteor's ecmascript package. I'm not sure what has to be done to make it compile that file properly.

billyvg commented 9 years ago

When you run it in an app, do you have the package locally in app/packages? It works if we do it this way, but if the package is loaded in the meteor package directory (~/.meteor/packages), it doesn't work.

The module that it fails to find is the rollbar-browser package.

billyvg commented 9 years ago

Now with commit 47b765cb68d1b8699882160f53b3415b4528dcc8, we are having issues with test-packages. When running meteor test-packages it looks for packages in app/.npm/package instead of app/packages/basic-logger/.npm/package

elidoran commented 9 years ago

finding the directories for all possibilities is a nightmare because the Build API doesn't tell my plugin where these things are. And, they can be a local package with the name as username:package or package. Or, a published package which is actually in the user's home directory now. And, local packages put the npm stuff into .npm/package, and, published packages put them in npm.

Basically, in Meteor 1.1 packages were built when they were published. Now, packages aren't built until an app including them is built. which means the build plugins must be able to build them while they are in a published form in the user's home directory with the npm stuff in a different place.

There are many awesome things about Meteor 1.2, but, all this extra work to find the npm modules in the file system is a nightmare without the API providing that information to the build plugin.

Anyway, I found the info way deep into the properties from an InputFile instance. It now works when the package is local or published and test-packages works whether you're in the package or not.

Please let me know if 0.8.0 solves your issues.

Also, 0.8.0 uses streaming only for the source map extraction, no writing/reading/deleting a file anymore.