npm package discovery and stats viewer.

Discover Tips

  • General search

    [free text search, go nuts!]

  • Package details

    pkg:[package-name]

  • User packages

    @[username]

Sponsor

Optimize Toolset

I’ve always been into building performant and accessible sites, but lately I’ve been taking it extremely seriously. So much so that I’ve been building a tool to help me optimize and monitor the sites that I build to make sure that I’m making an attempt to offer the best experience to those who visit them. If you’re into performant, accessible and SEO friendly sites, you might like it too! You can check it out at Optimize Toolset.

About

Hi, 👋, I’m Ryan Hefner  and I built this site for me, and you! The goal of this site was to provide an easy way for me to check the stats on my npm packages, both for prioritizing issues and updates, and to give me a little kick in the pants to keep up on stuff.

As I was building it, I realized that I was actually using the tool to build the tool, and figured I might as well put this out there and hopefully others will find it to be a fast and useful way to search and browse npm packages as I have.

If you’re interested in other things I’m working on, follow me on Twitter or check out the open source projects I’ve been publishing on GitHub.

I am also working on a Twitter bot for this site to tweet the most popular, newest, random packages from npm. Please follow that account now and it will start sending out packages soon–ish.

Open Software & Tools

This site wouldn’t be possible without the immense generosity and tireless efforts from the people who make contributions to the world and share their work via open source initiatives. Thank you 🙏

© 2024 – Pkg Stats / Ryan Hefner

@limarenkodenis/angular-components

v1.0.0

Published

Next generation components

Downloads

2

Readme

Getting started

Assuming we're starting with a new @angular/cli project:

$ npx @angular/cli new my-project --style=scss
$ cd my-project
$ npm i --save carbon-components-angular carbon-components @carbon/icons-angular

Then we need to include carbon-components in src/styles.scss:

@import "~carbon-components/scss/globals/scss/styles.scss";

Note: For offline usage we'll need to set $font-path: '~carbon-components/src/globals/fonts'; at the very top of our src/styles.scss. This will copy the fonts to our dist folder upon successful build. If you like the fonts to be a part of your assets folder and not pollute the dist folder then copy the fonts from node_modules/carbon-components/src/globals/fonts into our app's src/assets/fonts folder and add $font-path: '/assets/fonts/'; at the very top of our src/styles.scss.

That's it! Now we can run npm start and start building out our application!

Note: This isn't the only way to bootstrap a carbon-components-angular application, but the combination of @angular/cli and the carbon-components scss is our recommended setup.

Edit Carbon Components Angular

Contributing

Quickstart

  • fork IBM/carbon-components-angular and clone it locally
  • run npm install to grab all the dependencies, then npm run storybook to start storybook
  • if you are adding a component:
    • add a folder with your component code, styles, tests and story under src
    • export your module from index.ts
  • if you are contributing a fix:
    • add your fix, update the documentation as needed
    • consider adding or modifying a test case to cover the fix
  • follow the Angular style guide
  • be sure to run npm test and npm run lint to make sure the tests and linter pass
  • submit a PR

Pull request guidelines

  • Keep changes small and focused.
  • If you create a pull request and then realize it is not ready to be merged, prepend "WIP: " (For example, WIP: Fixed text overflow in accordion headers.) and assign a WIP label.
  • Include a description of changes
    • attach a screenshot (or a gif!) for design reference if needed
    • reference the related issue
      • "closes #123" or "fixes #123" will close issue #123 once the PR is merged
      • "issue #123" just references the issue. Only use this if you definitely need the issue to remain open.
    • @mention any specific other developers that need to be aware of the changes
  • add the "needs review" label along with any other relevant labels
  • link to code review checklist goes here

Issues submission guidelines

  • One issue per defect - do not open an issue that spans multiple defects
  • provide a descriptive title that mentions the component and version the issue covers
  • provide
    • version(s) affected
    • a description of the issue
    • steps taken to produce the issue
    • expected behaviour
    • current behaviour
    • screenshots if needed
    • relevant code snippets
    • links to application source code or running demo (Codesandbox is awesome for this!) (including connection/authentication information)
  • add relevant labels (bug, accessibility, design, discussion, feature, etc)
  • if you have a fix to contribute, assign yourself, otherwise leave unassigned

npm commands

To keep our build dependencies local we use npm scripts to run our webpack, gulp, and general build tasks. You should never install webpack or gulp globally as that will likely conflict with our version. You should never need to modify the build process to add a component or story.

  • npm run storybook to run storybook (port 6006)
  • npm run build to generate the dist
  • docs:build to build documentation
  • docs:server to build and run the documentation server
  • npm run lint to run tslint
  • npm test to run tests

Resources

Philosophy

  • Components should be the smallest unit of computation
    • Think in terms of pages and applications composed from a multitude of components rather than pages or applications as a single unit of computation
  • Components should delegate to the consumer whenever possible
    • The individual applications should be the single source of truth, and be able to create any UI from our building blocks
  • Components should do one thing, and do it well
    • This does not mean they should be over specialized, but rather focus on providing a single, core experience
  • Components should NOT maintain more state than absolutely necessary
    • Likewise, stateless components should be favored whenever possible
  • Components should NOT necessarily implement the style guide point-for-point, the guide simply provides guidance on overarching functionality, components should enable that and product specific designs without baking in extra functionality

Code of Conduct

Read our code of conduct here