Updates to the build article content for 1.3 #225
Conversation
| ``` | ||
|
|
||
| XXX: Is it `meteor npm` | ||
| XXX: Do we use --save-dev |
There was a problem hiding this comment.
It should be --save for production deps, and --save-dev for development deps, right? Another place where in Meteor the package specifies it (build plugin, debugOnly) and in NPM the user does.
There was a problem hiding this comment.
I mean... how does this actually work in practice? I mean the difference between dependencies and devDependencies has a fixed meaning for an npm module which is irrelevant to a meteor app, I would have thought. Unless the build tool respects this somehow?
There was a problem hiding this comment.
In an ideal world, when you deploy your app it would install your dependencies but not your devDependencies on the production server, so I think there's a valid distinction that a future Meteor tool should respect.
There was a problem hiding this comment.
There's no reason why someone couldn't do that right away so I think this makes a lot of sense, thinking about it more.
|
Is there some reason you decided to start documenting the PostCSS package? |
|
Yeah, I thought it was simple enough now and unlikely to change. |
|
Do you think it was a mistake to document it? |
|
No I think it's fine! You're right that it's a lot more straightforward when you don't have to worry about meteorhacks:npm. |
|
I think this is ready to merge @stubailo |
| @@ -79,7 +79,15 @@ One difference between pre-published packages and local app packages is that the | |||
|
|
|||
| <h4 id="npm-adding">Adding packages to your app</h4> | |||
|
|
|||
| Meteor 1.3 will have seamless integration with NPM, and you will be able to simply `npm install` these packages into your app directory. Until then, the easiest way to use NPM packages in your app is [`meteorhacks:npm`](https://atmospherejs.com/meteorhacks/npm). | |||
| To install an NPM package into your app, you can simply run NPM's standard install command: | |||
There was a problem hiding this comment.
This should mention that different versions of NPM do significantly different things, and that some packages might only work with NPM 2, but NPM 3 is better about deduplicating and path length on Windows. In short, we suggest NPM 3 but if that doesn't work for you try NPM 2. What do you think?
There was a problem hiding this comment.
Hmm, it's a good point. I don't really feel confident on this exact topic. Do we know NPM3 doesn't work for certain use cases? Because if not, perhaps we can leave it and expect people to just install whatever makes sense for them? It's pretty backwards compatible, right?
There was a problem hiding this comment.
NPM
It's pretty backwards compatible, right?
Top kek.
No but seriously libraries such as Relay don't work properly with NPM 3 sometimes. This is a fact: facebook/relay#832
Doesn't matter though - I think we should probably recommend NPM 3, and maybe people can figure it out.
There was a problem hiding this comment.
Should I just leave it or do think we should call out a specific version?
There was a problem hiding this comment.
I think we should, since "use NPM" is not specific, since there are three different NPMs that perform in dramatically different ways.
|
Just one more comment about NPM 2 vs. 3 and then we are good to go. |
|
Let's merge this; I'll need to reorganise this content once we have a Using Packages article anyway |
|
SGTM! |
Updates to the build article content for 1.3
Still some unanswered questions but I'm interested in your thoughts @stubailo
--savefor production deps, and--save-devfor development deps, right? Another place where in Meteor the package specifies it (build plugin, debugOnly) and in NPM the user does.dependenciesanddevDependencieshas a fixed meaning for an npm module which is irrelevant to a meteor app, I would have thought. Unless the build tool respects this somehow?dependenciesbut not yourdevDependencieson the production server, so I think there's a valid distinction that a future Meteor tool should respect.meteor creategives you an app with NPM dependencies. If we havemeteor create --reactor similar, that will be necessary, and I bet a Meteor 1.4 app will require NPM dependencies for some core Meteor stuff?package.jsin the boilerplate now? ....package.jsonfile, but maybe that's not so bad?npm installvs. Meteor somehow doing it for you, but we should try to figure out a way to warn users when their dependencies aren't installed? This could be as easy as something in.meteor/localwhich is a straight copy ofpackage.json, and complains if it's different.