Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bower-ifying the UX Pattern Library #136

Closed
Nickersoft opened this issue Jul 28, 2015 · 2 comments
Closed

Bower-ifying the UX Pattern Library #136

Nickersoft opened this issue Jul 28, 2015 · 2 comments
Assignees

Comments

@Nickersoft
Copy link
Contributor

As a developer from another team who uses the pattern library, I think it is crucial that proper Bower support be integrated with the pattern library (my original thought was NPM, but edX as an organization uses Bower to manage front-end dependencies). I tried playing around in my own branch, but ultimately this change is significant enough to warrant a dedicated effort. Some suggestions I have that could help this effort:

  • Separate the Jekyll site from the actual library, using Bower to install the pattern library as a dependency. This will help demonstrate the modularity of the Pattern Library and clean up the respective codebases significantly.
  • Include base .scss files with the pattern library that imports all of the components, so other developers don't have to do this manually. Right now, if you wish to use the pattern library, you must @import all of the components manually or modify a main-*.scss file, which currently resides in the documentation section of the repo. This makes it confusing for developers who wish to plug-and-play the library with little configuration. There should be a pattern-library-ltr.scss file as well as a pattern-library-rtl.scss file, which includes all of the needed imports.
  • Place all build scripts under 'exclude' in bower.json and instead include a 'dist' or 'bin' directory with the compiled Javascript and CSS. Due to the lack of nested dependencies in Bower, developers will need to import precompiled Javascript in order to use it (the same goes for CSS developers who aren't using SASS). Build scripts won't be able to run because all of the dependencies will be siblings, not children (see here).
  • Add all required SASS dependencies to a README. Because SASS can't be compiled without converting everything to CSS, SASS developers will need to import all of the dependencies manually in addition to the pattern library, similar to how imports are included in main-ltr.scss and main-rtl.scss. These dependencies should be formally documented in a README. JS dependencies wouldn't need to be documented given there is a compiled production version of the Javascript.

This is more of something to keep in mind, nothing extremely pressing. Just thoughts from someone who has tried using the pattern library. Let me know if you have any questions or comments. Thanks!

@talbs @frrrances

@talbs
Copy link
Contributor

talbs commented Sep 1, 2015

Thanks, @Nickersoft, for the good thoughts and inspiration. FYI, I just merged in #152 which moves our basic UXPL Sass partials and utilities into a Bower package. :)

Also, I've got a few more updates in the works for some of your other points:

  • Include base .scss files with the pattern library that imports all of the components, so other developers don't have to do this manually - See Simplify edx-pattern-library Sass Compilation #154
  • Separate the Jekyll site from the actual library, using Bower to install the pattern library as a dependency. - This is something that seems to require a separate repo (given the work done in Simplify edx-pattern-library Sass Compilation #154). I tried two separate branches (1 for the bower package/PL source code and another for the PLDOC site that would consume the package) before, but that causes a lot of headaches for local development that even bower link can help. Am I missing something?
  • Place all build scripts under 'exclude' in bower.json and instead include a 'dist' or 'bin' directory with the compiled Javascript and CSS. - The local PLDOC site compile gulp tasks have been ignored in the bower.json of our package. As far as referencing pre-compiled CSS, right now, Sass is required to use the edX PL code (as many of our features/utilities are A) Sass extends, functions and helpers or B) just starter-based CSS rules.
  • Add all required SASS dependencies to a README. - a damn fine idea and I've got an initial PR (Add Third Party and General Dependencies to README #155) out for it now. Its important to at least be up front with what third party packages we depend on. Thanks for the reminder.

Hope that helps keep you updated. I'll check back in on this issue in a bit to see if you have any ideas around how to get the PLDOC site using the actual bower package.

@talbs
Copy link
Contributor

talbs commented Sep 22, 2015

@Nickersoft, following up a bit...

Separate the Jekyll site from the actual library, using Bower to install the pattern library as a dependency.

I think this has been done through the bower package and its ignore settings. One can now install the package and use the full library without all of the doc site files. Currently, we still need a testbed to build new library patterns. Documenting them while doing so is a bonus :)


With that said, I think this (along with my original comments) addresses all of your feedback. I'm close this with that mind. Thanks much for the good inspiration.

If something else comes up or you think we need a deeper dive into anything here, feel free to comment or open a new issue.

@talbs talbs closed this as completed Sep 22, 2015
@talbs talbs self-assigned this Sep 22, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants