I installed the Polymer Starter Kit Light and am writing my first Polymer application.
I noticed that under bower_componets/polymer I have polymer.html, but the file has no indentation at all. I would love to follow the code and see what's going on, but the lack of indentation makes it less than ideal.
Running a simple bower install polymer gives you the same files.
In the GitHb project, https://github.com/Polymer/polymer , I cannot even find polymer.html.
So:
How is Polymer's code structured? How is the polymer.html generated?
How can I get a debug and tinker-friendly version of Polymer?
Polymer has development branches and releases.
If you bower install Polymer/polymer#master you get the master branch, which is very much like what you see in the GitHub repository.
If you bower install Polymer/polymer you get the latest release, which has been minified (only necessary files, and those files are combined and compressed) for your production benefit.
I'm afraid Polymers a bit complicated because it loads parts of itself dynamically, using the this._addFeatures function.
If you track back starting at Polymer.html, you will see it imports Polymer-mini.html which in turns imports Polymer-micro.html, which I think then loads something from the library.
polymer.html is imported in almost all the components. So even if you change the path in your element, it will be attempted to be imported from bower_components in some other element.
From what I understand, the HTML imports system keeps track of already imported items to ensure same code is not run twice. If you have polymer.html in two different path, it might attempt to run it twice and might lead to some issues.
So it is better to leave it in bower_components.
You can also try polygit (http://polygit.org/), if you are just playing around with polymer. Below is the sample plunker with polygit
http://plnkr.co/edit/QkxrrFHYZRnlHuZVNIgy
e.g.
<script src="http://polygit.org/components/webcomponentsjs/webcomponents-lite.js"></script>
<link rel="import" href="http://polygit.org/components/polymer/polymer.html">
<link rel="import" href="http://polygit.org/components/paper-input/paper-input.html">
Related
Using clojurescript 1.10.758 and reagent 1.0.0, I am running into an error in which a file index.js tries to reference $jscomp, which is not defined.
I've seen a number of Stackoverflow and Github issues related to $jscomp being undefined in the context of shadow-cljs, but I'm not using that.
The problem occurs when I use a development mode build with figwheel (using Leiningen with cljsbuild and the figwheel plugin), and also occurs if I use cljsbuild for a once-only development build. Strangely, if I use webpack to create a bundle, the problem does not occur.
Before I tried to make webpack work, I did have working code without webpack. Something I changed seems to have affected the non-bundled build. The only change I can thing of was to install react and react-dom using npm, and exclude those packages from reagent in Leiningen's dependencies. But undoing the exclusion didn't make the non-bundled code work again.
Any suggestions for how to cause $jscomp to be defined when it's first needed?
$jscomp is related to the Closure Compiler and the Polyfills it creates.
It might be enough to tweak the :language-out :es6 compiler options which is somewhat similar to the :output-feature-set option used by shadow-cljs. The best way to debug this is finding the actual code that is getting polyfilled and why. Might require digging through some compiled JS though.
shadow-cljs uses the Closure Compiler more extensively than regular CLJS or figwheel but they also use it. Solutions that apply to shadow-cljs pretty much apply to other tools as well. Just the settings may work a little differently.
Why and how does Polymer use Bower?, and do I NEED to learn to use Bower to use Polymer?
I was going through the Catalog of components, and all of them seem to have a 'Bower Command'.
Thanks for your help.
Edit: Bower is a package manager just as npm, I do understand that much. What I meant to ask is: It can be argued that npm has a wider user base than Bower some even argue that we should stop using bower altogether like here and here. So, how is it beneficial to Polymer the use of bower when there are other options. Is what Polymer does only achievable through bower?
Bower just like npm is a package manager. Here you can see the difference between the two.
No, you don't need to use bower to use Polymer, but without that you'll have to manually download each components that you need, place it at the location from where you can refer it and keep track of newer versions of each package that you have used.
In case you are creating custom elements to publish the situation get even worse as you'll have to pass a file along with your project listing all the dependency and the user will have to manually download each dependency listed in your project and then will have to make sure that he has all the dependencies that were required by your dependencies and so on.
This will make process of custom elements or modules in general very hard to use. That's why such projects use some package management tool.
Edit: since the original question has been edited to ask more about why, the short answer is Bower's focus was for web dependencies, so it results in a flat dependency tree. With Bower now deprecated, the Polymer team's recommendation is to use Yarn with the --flat option. That will also result in a flat dependency structure without multiple versions of the same dependency, which is critical to web development, and something NPM has stated they will never offer.
You should be seeing Components move from Bower to Yarn more, especially after Polymer 3 is released. For more information than you'd ever want about this topic, check out this discussion: https://github.com/package-community/discussions/issues/2
I am trying to import several SCSS files(page1.scss, page2.scss and ..) in my app.scss but I haven't found any solution(plugin and etc).
I saw these answers but they are for Ruby on Rails not libsass. I am using:
Gulp,
Gulp-sass,
Libsass and
Laravel Elixir
Any solution?
Long answer short:
As you can find in this issue in the official libsass project github, globs are not part of SASS specification, so there are no plans to support them in libsass.
why?
The main concern about implementing this feature is related with the order importing the files. In first place, AFAIK there isn't a standard way on how reading stream files behave in different OSs (linux, mac os x, windows) or filesystems (reiserfs, ext3, ntfs, fat32, etc.), what leads to a unpredictable ordering while importing the files.
Anyway, even if there will be some sort of cross-platform standard support to read files from every filesystem and you are sure you are always gonna get the files in the same order. Which order should it be?.
if you still need/want it:
Still there are some hack-y ways you can achieve this behaviour but I will strongly recommend to avoid them and follow the official recommendations.
There is a ruby gem: sass-globbing. But it doesn't works with gulp/libsass because of the different way they handle files streams. Inspired on this ruby-gem there is gulp-css-globbing. It looks like this project is a bit outdated, but you can use it on your own risk.
And in this blog post: Sass Directory Imports With Gulp, you can find another solution that involve automatically creating a file per folder that imports all files inside. A bit convoluted for my taste but it will work if you really need this.
Recently Polymer updated from 0.5.2 to 0.5.3. Some of these changes affect the styling of my components, e.g.:
paper-checkbox
Updated paper-checkbox to match Material Design guidelines
To style properly, must now set border-color along with background-color
My bower include targets a specific version:
"paper-elements": "Polymer/paper-elements#0.5.2"
but bower.json in paper-elements uses the carat:
"paper-checkbox": "Polymer/paper-checkbox#^0.5.0"
so when I run bower update it happily fetches paper-checkbox version 0.5.4.
Is there a way to ensure bower grabs a specific version of these dependencies, without having to list every single package in my own bower.json? E.g., I could explicitly specify paper-checkbox#0.5.2, but because paper-checkbox has its own dependencies using the carat syntax, I'd have to include all dependencies of all the elements I use recursively.
Am I just supposed to immediately update my code whenever a new Polymer minor version is released?
I guess the answer is yes, I do need to explicitly list all dependencies in the entire dependency graph if I want to ensure bower pulls down exact versions of those packages. Oh well!
I'm working on a project with two other developers that's built on FireBreath. So far, I've been able to get things working perfectly on my machine, but we need to coordinate our development via Mercurial. So I pushed my files to the repository and thought all was well.
Unfortunately, that doesn't work.
The various .vcproj files that make up the solution all contain hard-coded references to my local file system. This works fine for me, because I'm not moving the project around. But when you try to build the solution on another machine with a different file structure (different drive letter, different folder location, etc.) everything breaks.
I used FireBreath's standard project generation script (Python) and then the Visual Studio CMake script (prep2008.cmd) to generate the solution files. What can I do to tweak things so that other developers can use the same code base?
If your developers are not using the same build/make/project files, this could quickly become a maintenance nightmare. So you should definitively all use the same .vcproj files. (An exception to this would be if the project files were generated from some other files. In that case treat those other files in the way described above.)
there's two ways to deal with the problem of differing setups on different machines. One is to make all paths relative to the project's path. The other is to use environment variables to refer to files/tools/libraries/whatever. IME it's best to use relative paths for everything that can be checked out with the project, and use environment variables for the rest. Add a script that checks for the existence of all necessary environment variable, pointing out the meaning of any missing ones, and run this as a build prerequisite, so whoever tries to get a new build machine up and running gets hints at what to do.
To make sure that everyone caught the updated comments from sbi's answer, let me give you the "definitive" answer from the FireBreath devs.
Your build directory is disposable; you should never share .vcproj files. Instead, you should regenerate your build/ directory any time you change the project and on each new computer, just like any project that uses CMake.
For more information, see http://colonelpanic.net/2010/11/firebreath-tips-working-with-source-control/
For reference, I am the primary author of FireBreath and I wrote the article.
I'm not familiar with FireBreath, but you need to make the references relative, and then recreate that relative structure on every machine. That is, if your project sits in "c:\myprojects\thisproject" and has an additional include directory "c:\mydir\mylib\include", then the latter path needs to be replaced with "....\mydir\mylib\include".
EDIT: I rewrote my anyswer to make it clearer. When I got you correctly, your problem is that FireBreath generates those .vcproj files with absolute paths in it, and you want to use this .vcproj files on a different developer machine.
I see 3 options:
Live with it. That means, make sure, every team member has the same file structure / view to the file system, tools installed in the same place.
Ask the authors of FireBreath to change their .vcproj generator to allow relative paths, use of environment variables etc.
If 1 or 2 does not work, write a program or script for changing the absolute path to relatives in those .vcproj files. Run this script whenever you have to regenerate your FireBreath project.
What you should not do due to the FireBreath FAQ: don't change the .vcproj manually, those changes will be lost next time the project is regenerated.
EDIT: seems that "option 4." turned out to be the best solution: generating those .vcproj files for each developer individually. Hope my suggestions were helpful, either.