I’ve been working on an React/Material UI application and would like to create a packaged component that uses the accounts system.
I decided I’d like to create it as an NPM, but later found there appears to be no equivalent to api.imply or api.use when using npms, and as I needed to api.use/imply accounts-base I didn’t know how to continue.
So I decided I’d go the tried and tested Meteor package route. I used api.use to depend on accounts-base/accounts-password. Then I created an Npm.depends section and tried to add Material UI the same way I did in my apps package.json by doing something like this:
Npm.depends({
'material-ui': '^0.14.3'
});
But this doesn’t work because Npm.depends doesn’t support ^ and requires an exact version number.
This doesn’t seem great because my app version of material UI will update and I’ll have to keep bumping the version number in the package manually. If the version numbers ever get out of sync, does that also mean I’m building two versions of material UI into my app?
Right now I don’t know where to go with meteor packages lacking npm version ranges and npms lacking the ability to api.imply/use.
Well, I tried this out and it works for now but it seems like a really bad solution in general. What if someone removes my package? Now they have npms they don’t even need because they basically installed them manually. People aren’t going to remember which npms a package they installed 3 months ago asked them to install.
Long term MDG has stated they expect to move all packages to NPM. If you made your package an NPM package today could you not use import from instead of api.use thanks to the 1.3 modules system? Packages moved to NPM can import APIs from other Meteor packages on NPM or from any Meteor core packages that remain only on Atmosphere. You may have to wait until MDG supports import of assets from an NPM package, which is being tracked here.
I understand we can import an atmosphere package from an NPM but as far as I understand it, this doesn’t cause the package to be installed. Am I mistaken?
If we write a Meteor package we have to tell the user to manually install any NPM dependencies.
If we write an NPM we have to tell the user to manually install any atmosphere dependencies.
If we remove either a Meteor package or an NPM right now it seems there’s the strong possibility that we now have unnecessary NPMs or Atmosphere dependencies installed.
I think you got it! I agree, not ideal, but probably unavoidable right now mixing two package systems that have slightly different ways of doing things.
Right, it should resolve itself once we see more packages move to NPM. I just wanted to check this truly is the situation right now and I wasn’t missing something. Thanks!
In a Meteor package, if you want an npm package just for use inside your package, you should use Npm.depends(), and all this stuff will be deleted if the user removes the package.
If you want to use an npm package that you think the user will have installed in their app, the so-called “peer” dependency, i.e. React, then don’t call Npm.depends() and Meteor will use the main app’s version. Yes, if your package is removed, the npm package will remain, but usually in this case it’s an npm package that the user had anyway and specifically chose your Meteor package because it will use this.
If you’re writing an NPM package with Atmosphere dependencies, I think at this stage it’s better to rather write an Atmosphere package. There’s a drive to move a lot of the Meteor core packaegs to NPM though, which will help a lot moving forward.
Yes after thinking about it the current situation seems fine. The only thing lacking is that we’re forced to Npm.depends on a specific version. It would be really nice if ^ formats and 0.x.x rules were implemented for Npm.depends. In the end I’ve stuck with a meteor package that doesn’t use Npm.depends at all and just asked that people install the few npms they need.
Just to add a conclusion to this thread for anyone else wondering the same, here’s what Sashko had to say:
Meteor packages are built when they are published, so by the time the user has downloaded your package, they don’t get to decide which NPM dependency version to use since the code is baked in. If you want the application developer to decide which version of an NPM package to use in the particular app, use the new mechanism of peer NPM dependencies, described here: