I'm creating a npm package that only contains Sass, a small framework. I only want this package to contain the Sass (and a few grunt plugins) so that someone can install and build it without installing the documentation.
But in the case where someone wants to contribute to the project having only the Sass files isn't all that helpful. They would need the documentation (or an example) to view the changes.
So I would like 2 packages; 1 for the framework and 1 for the documentation.
The documentation package would require the framework, the framework package may or may not require the documentation. (You would never update the framework from documentation, only the documentation, but the framework is needed.)
Documentation required = wanting to contribute to framework
Documentation not required = just wanting to use the framework in a project
Basically, I want to give the person installing the framework the option of getting the docs or not.
Is this possible using dependencies vs devDependencies vs peerDependencies?
Thanks!
From above:
To someone who wants to contribute, wouldn't Github be a better option? They could just clone the repo instead of installing it from npm. You could use npmignore to ignore all the documentation from npm package, which will still remain on Github
Thanks #laggingreflex
Related
I've built a custom style "skin" on top of bootstrap that I intend to use in multiple UI projects.
Rather than copying/pasting the UI styles/components (built using sass and typescript in my current Angular 5 project), I want to build an NPM package that I can install these styles and components I've built in new projects, thus allowing updates to be done to the NPM package (maybe extending the controls within for example) without breaking the UI's using them or needing to update files within.
I've never setup an NPM project before. I've found a number of examples of how to build NPM packages, for example https://codeforgeek.com/2014/08/how-to-create-nodejs-npm-package/ but it seems to be for vanilla JS in this example. I need an example which:
Builds on a dependency, in this case bootstrap
Is to be used in Angular (I'm using version 5)
Is installable and updatable via NPM or maybe Yarn
Has anyone any top tips on achieving the above? Or any really clear guides where someone has done this before?
I realise this question is relatively broad but really I just need some pointers to get started and I will document the process further when I have a better understanding.
Thanks in advance!
So you should move your theme into a separate project. Then all you have to do is run npm init in that directory and you have a npm.
As for sharing it between projects, I would create a repo on Github for this theme npm. Push all of your changes there. Then you can reference it in the package.json of all your projects by linking to the Github repo. Here is a good Stack question about how to do that.
Finally, if you want to develop your theme locally inside one of your projects, you can use npm link. Here are he docs on that.
I'm just reviewing some dependencies of an angular project.
During that, I had to figure out, that I couldn't find any description for the single angular sub packages describing their purpose.
Example:
#angular/platform-server
When browsing to the API documentation or the npm package page, there is literally no description explaining the purpose of those packages:
https://angular.io/api/platform-server
https://www.npmjs.com/package/#angular/platform-server
https://github.com/angular/angular/tree/master/packages/platform-server
https://angular.io/guide/npm-packages#feature-packages
I think this where all the official sources. But no word about #angular/platform-server lost.
Is there any official documentation which includes this? Or does this simply not exist? I don't want to have tons of packages in my dependencies of which I have no idea of what they do and if I need them at all.
I understand that packages hold several modules, but I'm starting to get confused as to if packages and modules are dependencies. Also, libraries to me maybe seem like packages you install via NPM, Nuget, RubyGems, Bower, Homebrew, or Chocolatey. So are libraries packages? Dependencies are something you need to load within your application, to have a certain functionality, but aren't some libraries(jQuery) seen as a dependency? So yea, what are the differences between these concepts?
Libraries are just a bunch of code anyone can use. For example, React.js is a JavaScript library for building front end components.
If I decide to use this library in my app, then React will become one of the modules (aka an installed instance of the library) that my app depends on. So dependencies are pretty much all of the libraries your app depends on, in order to run the way you expect it to run.
I asked the same question you did about dependencies, and I learned that it's a matter of understanding how these terms relate to one another rather than finding isolated definitions for each of them.
Hope this helps!
Basically a package is a pack with some features which fullfills some functionality of your app.
Once you install any package using npm then the package is installed as a dependency in your app inside your package.json file along with its modules(aka libraries consist of classes) stored inside node_modules folder.
I hope its clear now.
I'm checking out tons of blogs like this one where it's explicitly stated that Bower is the preferred and recommended way install Bootstrap to my Core web app.
The recommended way to install client-side dependencies like Bootstrap in ASP.NET Core is via Bower (using bower.json, as shown above). The use of npm/NuGet are shown to demonstrate how easily Bootstrap can be added to other kinds of web applications, including earlier versions of ASP.NET.
Checking the date of the post seems to be settling as it's only a few weeks old but when I check e.g. the icon for dependencies and some other things, I'm getting the impression that the content might be actually a bit more aged than so.
I've been googlearching lately and I learned that there's a shift towards fewer-simpler-smaller approach. Especially I've discovered that NPM is often recommended for managing all the packages, including Bootstrap. (Now, just because someone says so, it doesn't automatically makes it true - we need to ask why would the one or the other approach be more advantageous.)
Question - what's the downside of using Bower to manage Bootstrap instead of installing it with NPM and omitting Bower all together?
I think that since bootstrap is a strictly front-end framework, the recommendation was to install it via bower. If you envision having server-side javascript in your project as well, then npm would be the recommended way to go now :)
How should we deal with local packages that are a dependency in other local packages?
For simplicities sake, say we have the follow packages
api - express application
people - a package to deal with people
data-access - a package that deals with data access
And then the dependencies are
api depends on people
people depends on data-access
Currently we have these dependencies setup as file dependencies.
I.e. api package.json would have
"dependencies": {
"people": "file:../people"
}
Trouble with this is that we're finding it a PITA when we make updates to one package and want those changes in the other packages that depend on it.
The options we have thought of are:
npm install - but this won't overwrite previously installed packages if changes are made, so we have to delete the old one from the node_modules directory and re-run npm install... which can be niggly if the package dependency is deep.
npm link - we're not sold on the idea because it doesn't survive version control... Just thinking about it now, maybe we have some kind of local build script that would run the npm link commands for us... this way it could survive version control. Would that be a grunt job?
grunt - we haven't dived too deep into this one yet, but it feels like a good direction. A little bit of googling we came accross this: https://github.com/ahutchings/grunt-install-dependencies
So, what option would work best for our situation?
Are there other options that we haven't thought of yet?
Ps. we're a .NET shop doing a PoC in node, so assume we know nothing!
Pps. if you strongly believe we're setting up our project incorrectly and we shouldn't have smaller individual packages, let me know in the comments with a link to some reading on the subject.
So, I agree that going with 'many small packages' is usually a good idea. Check out 12factor.net if you haven't already.
That said, in specific answer to your question I'd say your best bet is to consider mainly how you want to maintain them.
If the 'subcomponents' are all just parts of your app (as, for example, data-access implies), then I'd keep them in the same folder structure, not map them in package.json at all, and just require them where you need them. In this case, everything versions together and is part of the same git repository.
If you really want to or need to keep them all in separate git repositories, then you can do npm link, but to be honest I've found it more useful to just use the URL syntax in package.json:
dependencies: {
"people" : "git://path.to.git:repo#version.number"
}
Then, when you want to explicitly update one of your dependencies, you just have to bump the version number in your package.json and run npm install again.