add introduction #20
add introduction #20
Conversation
per [comment](fxpio#18 (comment)) in fxpio#18 I've added an overview/explanation of the basic concepts
|
|
||
| This makes it possible (and automates the process of) installing and updating npm-packages that ship with your Composer packages, leveraging the native (`npm` or `yarn`) package manager to do the heavy lifting. | ||
|
|
||
| For this approach to work well, you should think of an npm-package in a Composer package not just as an "artifact", but as an actual npm-package *embedded* in your Composer package. |
There was a problem hiding this comment.
I don't really agree to this paragraph, since to my understanding the npm packages are less tied to composer packages with foxy.
There was a problem hiding this comment.
"less tied", maybe, but they're still directly dependent on updating the Composer package? the only way to update the npm-package is by updating the Composer package, since they're literally in the same source-repo.
feel free to change/remove anything you want though, it's your project - just trying to help :-)
There was a problem hiding this comment.
the only way to update the npm-package is by updating the Composer package
You mean the "npm-package constraints" ? Maybe it's just a misunderstanding or terminology...
it's your project - just trying to help :-)
Me too :)
There was a problem hiding this comment.
I think:
npm packages are less tied to composer packages with foxy`
Because you can very well use the Composer package without installing the npm-packages (if Foxy is optional for the package), which was not really the case with Composer Asset Plugin.
For this approach to work well, you should think of an npm-package in a Composer package not just as an "artifact", but as an actual npm-package embedded in your Composer package.
If Foxy is used, in this case, the package.json file is updated only when the Composer package is updated, given that it is included in the package. So in this case, the npm-package is 'tied' with the Composer package.
There was a problem hiding this comment.
maybe my thinking/understanding is different from yours?
For this approach to work well, you should think of an npm-package in a Composer package not just as an "artifact"...
By this I mean, a lot of people currently create an npm-package with no name or version number - an "artifact" in the sense that this isn't really a package that ever gets installed, it's just a means of setting up your Composer project's client-side requirements.
...you should think of an npm-package in a Composer package ... as an actual npm-package embedded in your Composer package.
That is, I don't think anybody is going to push a built-in npm-package to a repository server - they're most likely just looking to use this tool as a means of managing client-side dependencies built-into a Composer package.
Maybe my understanding is completely different from yours :-)
There was a problem hiding this comment.
as said, feel free to rephrase or change anything I wrote - I'm just trying to formulate it in a way where I think I'd have been able to understand it myself :-)
|
@mindplay-dk Thank you! |
per comment in #18 I've added an overview/explanation of the basic concepts.
I hope this is helpful :-)